1 ==========================================
2 The LLVM Target-Independent Code Generator
3 ==========================================
5 .. role:: raw-html(raw)
11 .unknown { background-color: #C0C0C0; text-align: center; }
12 .unknown:before { content: "?" }
13 .no { background-color: #C11B17 }
14 .no:before { content: "N" }
15 .partial { background-color: #F88017 }
16 .yes { background-color: #0F0; }
17 .yes:before { content: "Y" }
18 .na { background-color: #6666FF; }
19 .na:before { content: "N/A" }
26 This is a work in progress.
31 The LLVM target-independent code generator is a framework that provides a suite
32 of reusable components for translating the LLVM internal representation to the
33 machine code for a specified target---either in assembly form (suitable for a
34 static compiler) or in binary machine code format (usable for a JIT
35 compiler). The LLVM target-independent code generator consists of six main
38 1. `Abstract target description`_ interfaces which capture important properties
39 about various aspects of the machine, independently of how they will be used.
40 These interfaces are defined in ``include/llvm/Target/``.
42 2. Classes used to represent the `code being generated`_ for a target. These
43 classes are intended to be abstract enough to represent the machine code for
44 *any* target machine. These classes are defined in
45 ``include/llvm/CodeGen/``. At this level, concepts like "constant pool
46 entries" and "jump tables" are explicitly exposed.
48 3. Classes and algorithms used to represent code as the object file level, the
49 `MC Layer`_. These classes represent assembly level constructs like labels,
50 sections, and instructions. At this level, concepts like "constant pool
51 entries" and "jump tables" don't exist.
53 4. `Target-independent algorithms`_ used to implement various phases of native
54 code generation (register allocation, scheduling, stack frame representation,
55 etc). This code lives in ``lib/CodeGen/``.
57 5. `Implementations of the abstract target description interfaces`_ for
58 particular targets. These machine descriptions make use of the components
59 provided by LLVM, and can optionally provide custom target-specific passes,
60 to build complete code generators for a specific target. Target descriptions
61 live in ``lib/Target/``.
63 6. The target-independent JIT components. The LLVM JIT is completely target
64 independent (it uses the ``TargetJITInfo`` structure to interface for
65 target-specific issues. The code for the target-independent JIT lives in
66 ``lib/ExecutionEngine/JIT``.
68 Depending on which part of the code generator you are interested in working on,
69 different pieces of this will be useful to you. In any case, you should be
70 familiar with the `target description`_ and `machine code representation`_
71 classes. If you want to add a backend for a new target, you will need to
72 `implement the target description`_ classes for your new target and understand
73 the :doc:`LLVM code representation <LangRef>`. If you are interested in
74 implementing a new `code generation algorithm`_, it should only depend on the
75 target-description and machine code representation classes, ensuring that it is
78 Required components in the code generator
79 -----------------------------------------
81 The two pieces of the LLVM code generator are the high-level interface to the
82 code generator and the set of reusable components that can be used to build
83 target-specific backends. The two most important interfaces (:raw-html:`<tt>`
84 `TargetMachine`_ :raw-html:`</tt>` and :raw-html:`<tt>` `DataLayout`_
85 :raw-html:`</tt>`) are the only ones that are required to be defined for a
86 backend to fit into the LLVM system, but the others must be defined if the
87 reusable code generator components are going to be used.
89 This design has two important implications. The first is that LLVM can support
90 completely non-traditional code generation targets. For example, the C backend
91 does not require register allocation, instruction selection, or any of the other
92 standard components provided by the system. As such, it only implements these
93 two interfaces, and does its own thing. Note that C backend was removed from the
94 trunk since LLVM 3.1 release. Another example of a code generator like this is a
95 (purely hypothetical) backend that converts LLVM to the GCC RTL form and uses
96 GCC to emit machine code for a target.
98 This design also implies that it is possible to design and implement radically
99 different code generators in the LLVM system that do not make use of any of the
100 built-in components. Doing so is not recommended at all, but could be required
101 for radically different targets that do not fit into the LLVM machine
102 description model: FPGAs for example.
104 .. _high-level design of the code generator:
106 The high-level design of the code generator
107 -------------------------------------------
109 The LLVM target-independent code generator is designed to support efficient and
110 quality code generation for standard register-based microprocessors. Code
111 generation in this model is divided into the following stages:
113 1. `Instruction Selection`_ --- This phase determines an efficient way to
114 express the input LLVM code in the target instruction set. This stage
115 produces the initial code for the program in the target instruction set, then
116 makes use of virtual registers in SSA form and physical registers that
117 represent any required register assignments due to target constraints or
118 calling conventions. This step turns the LLVM code into a DAG of target
121 2. `Scheduling and Formation`_ --- This phase takes the DAG of target
122 instructions produced by the instruction selection phase, determines an
123 ordering of the instructions, then emits the instructions as :raw-html:`<tt>`
124 `MachineInstr`_\s :raw-html:`</tt>` with that ordering. Note that we
125 describe this in the `instruction selection section`_ because it operates on
128 3. `SSA-based Machine Code Optimizations`_ --- This optional stage consists of a
129 series of machine-code optimizations that operate on the SSA-form produced by
130 the instruction selector. Optimizations like modulo-scheduling or peephole
131 optimization work here.
133 4. `Register Allocation`_ --- The target code is transformed from an infinite
134 virtual register file in SSA form to the concrete register file used by the
135 target. This phase introduces spill code and eliminates all virtual register
136 references from the program.
138 5. `Prolog/Epilog Code Insertion`_ --- Once the machine code has been generated
139 for the function and the amount of stack space required is known (used for
140 LLVM alloca's and spill slots), the prolog and epilog code for the function
141 can be inserted and "abstract stack location references" can be eliminated.
142 This stage is responsible for implementing optimizations like frame-pointer
143 elimination and stack packing.
145 6. `Late Machine Code Optimizations`_ --- Optimizations that operate on "final"
146 machine code can go here, such as spill code scheduling and peephole
149 7. `Code Emission`_ --- The final stage actually puts out the code for the
150 current function, either in the target assembler format or in machine
153 The code generator is based on the assumption that the instruction selector will
154 use an optimal pattern matching selector to create high-quality sequences of
155 native instructions. Alternative code generator designs based on pattern
156 expansion and aggressive iterative peephole optimization are much slower. This
157 design permits efficient compilation (important for JIT environments) and
158 aggressive optimization (used when generating code offline) by allowing
159 components of varying levels of sophistication to be used for any step of
162 In addition to these stages, target implementations can insert arbitrary
163 target-specific passes into the flow. For example, the X86 target uses a
164 special pass to handle the 80x87 floating point stack architecture. Other
165 targets with unusual requirements can be supported with custom passes as needed.
167 Using TableGen for target description
168 -------------------------------------
170 The target description classes require a detailed description of the target
171 architecture. These target descriptions often have a large amount of common
172 information (e.g., an ``add`` instruction is almost identical to a ``sub``
173 instruction). In order to allow the maximum amount of commonality to be
174 factored out, the LLVM code generator uses the
175 :doc:`TableGen/index` tool to describe big chunks of the
176 target machine, which allows the use of domain-specific and target-specific
177 abstractions to reduce the amount of repetition.
179 As LLVM continues to be developed and refined, we plan to move more and more of
180 the target description to the ``.td`` form. Doing so gives us a number of
181 advantages. The most important is that it makes it easier to port LLVM because
182 it reduces the amount of C++ code that has to be written, and the surface area
183 of the code generator that needs to be understood before someone can get
184 something working. Second, it makes it easier to change things. In particular,
185 if tables and other things are all emitted by ``tblgen``, we only need a change
186 in one place (``tblgen``) to update all of the targets to a new interface.
188 .. _Abstract target description:
189 .. _target description:
191 Target description classes
192 ==========================
194 The LLVM target description classes (located in the ``include/llvm/Target``
195 directory) provide an abstract description of the target machine independent of
196 any particular client. These classes are designed to capture the *abstract*
197 properties of the target (such as the instructions and registers it has), and do
198 not incorporate any particular pieces of code generation algorithms.
200 All of the target description classes (except the :raw-html:`<tt>` `DataLayout`_
201 :raw-html:`</tt>` class) are designed to be subclassed by the concrete target
202 implementation, and have virtual methods implemented. To get to these
203 implementations, the :raw-html:`<tt>` `TargetMachine`_ :raw-html:`</tt>` class
204 provides accessors that should be implemented by the target.
208 The ``TargetMachine`` class
209 ---------------------------
211 The ``TargetMachine`` class provides virtual methods that are used to access the
212 target-specific implementations of the various target description classes via
213 the ``get*Info`` methods (``getInstrInfo``, ``getRegisterInfo``,
214 ``getFrameInfo``, etc.). This class is designed to be specialized by a concrete
215 target implementation (e.g., ``X86TargetMachine``) which implements the various
216 virtual methods. The only required target description class is the
217 :raw-html:`<tt>` `DataLayout`_ :raw-html:`</tt>` class, but if the code
218 generator components are to be used, the other interfaces should be implemented
223 The ``DataLayout`` class
224 ------------------------
226 The ``DataLayout`` class is the only required target description class, and it
227 is the only class that is not extensible (you cannot derive a new class from
228 it). ``DataLayout`` specifies information about how the target lays out memory
229 for structures, the alignment requirements for various data types, the size of
230 pointers in the target, and whether the target is little-endian or
235 The ``TargetLowering`` class
236 ----------------------------
238 The ``TargetLowering`` class is used by SelectionDAG based instruction selectors
239 primarily to describe how LLVM code should be lowered to SelectionDAG
240 operations. Among other things, this class indicates:
242 * an initial register class to use for various ``ValueType``\s,
244 * which operations are natively supported by the target machine,
246 * the return type of ``setcc`` operations,
248 * the type to use for shift amounts, and
250 * various high-level characteristics, like whether it is profitable to turn
251 division by a constant into a multiplication sequence.
253 .. _TargetRegisterInfo:
255 The ``TargetRegisterInfo`` class
256 --------------------------------
258 The ``TargetRegisterInfo`` class is used to describe the register file of the
259 target and any interactions between the registers.
261 Registers are represented in the code generator by unsigned integers. Physical
262 registers (those that actually exist in the target description) are unique
263 small numbers, and virtual registers are generally large. Note that
264 register ``#0`` is reserved as a flag value.
266 Each register in the processor description has an associated
267 ``TargetRegisterDesc`` entry, which provides a textual name for the register
268 (used for assembly output and debugging dumps) and a set of aliases (used to
269 indicate whether one register overlaps with another).
271 In addition to the per-register description, the ``TargetRegisterInfo`` class
272 exposes a set of processor specific register classes (instances of the
273 ``TargetRegisterClass`` class). Each register class contains sets of registers
274 that have the same properties (for example, they are all 32-bit integer
275 registers). Each SSA virtual register created by the instruction selector has
276 an associated register class. When the register allocator runs, it replaces
277 virtual registers with a physical register in the set.
279 The target-specific implementations of these classes is auto-generated from a
280 :doc:`TableGen/index` description of the register file.
284 The ``TargetInstrInfo`` class
285 -----------------------------
287 The ``TargetInstrInfo`` class is used to describe the machine instructions
288 supported by the target. Descriptions define things like the mnemonic for
289 the opcode, the number of operands, the list of implicit register uses and defs,
290 whether the instruction has certain target-independent properties (accesses
291 memory, is commutable, etc), and holds any target-specific flags.
293 The ``TargetFrameLowering`` class
294 ---------------------------------
296 The ``TargetFrameLowering`` class is used to provide information about the stack
297 frame layout of the target. It holds the direction of stack growth, the known
298 stack alignment on entry to each function, and the offset to the local area.
299 The offset to the local area is the offset from the stack pointer on function
300 entry to the first location where function data (local variables, spill
301 locations) can be stored.
303 The ``TargetSubtarget`` class
304 -----------------------------
306 The ``TargetSubtarget`` class is used to provide information about the specific
307 chip set being targeted. A sub-target informs code generation of which
308 instructions are supported, instruction latencies and instruction execution
309 itinerary; i.e., which processing units are used, in what order, and for how
312 The ``TargetJITInfo`` class
313 ---------------------------
315 The ``TargetJITInfo`` class exposes an abstract interface used by the
316 Just-In-Time code generator to perform target-specific activities, such as
317 emitting stubs. If a ``TargetMachine`` supports JIT code generation, it should
318 provide one of these objects through the ``getJITInfo`` method.
320 .. _code being generated:
321 .. _machine code representation:
323 Machine code description classes
324 ================================
326 At the high-level, LLVM code is translated to a machine specific representation
327 formed out of :raw-html:`<tt>` `MachineFunction`_ :raw-html:`</tt>`,
328 :raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>`, and :raw-html:`<tt>`
329 `MachineInstr`_ :raw-html:`</tt>` instances (defined in
330 ``include/llvm/CodeGen``). This representation is completely target agnostic,
331 representing instructions in their most abstract form: an opcode and a series of
332 operands. This representation is designed to support both an SSA representation
333 for machine code, as well as a register allocated, non-SSA form.
337 The ``MachineInstr`` class
338 --------------------------
340 Target machine instructions are represented as instances of the ``MachineInstr``
341 class. This class is an extremely abstract way of representing machine
342 instructions. In particular, it only keeps track of an opcode number and a set
345 The opcode number is a simple unsigned integer that only has meaning to a
346 specific backend. All of the instructions for a target should be defined in the
347 ``*InstrInfo.td`` file for the target. The opcode enum values are auto-generated
348 from this description. The ``MachineInstr`` class does not have any information
349 about how to interpret the instruction (i.e., what the semantics of the
350 instruction are); for that you must refer to the :raw-html:`<tt>`
351 `TargetInstrInfo`_ :raw-html:`</tt>` class.
353 The operands of a machine instruction can be of several different types: a
354 register reference, a constant integer, a basic block reference, etc. In
355 addition, a machine operand should be marked as a def or a use of the value
356 (though only registers are allowed to be defs).
358 By convention, the LLVM code generator orders instruction operands so that all
359 register definitions come before the register uses, even on architectures that
360 are normally printed in other orders. For example, the SPARC add instruction:
361 "``add %i1, %i2, %i3``" adds the "%i1", and "%i2" registers and stores the
362 result into the "%i3" register. In the LLVM code generator, the operands should
363 be stored as "``%i3, %i1, %i2``": with the destination first.
365 Keeping destination (definition) operands at the beginning of the operand list
366 has several advantages. In particular, the debugging printer will print the
367 instruction like this:
373 Also if the first operand is a def, it is easier to `create instructions`_ whose
374 only def is the first operand.
376 .. _create instructions:
378 Using the ``MachineInstrBuilder.h`` functions
379 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
381 Machine instructions are created by using the ``BuildMI`` functions, located in
382 the ``include/llvm/CodeGen/MachineInstrBuilder.h`` file. The ``BuildMI``
383 functions make it easy to build arbitrary machine instructions. Usage of the
384 ``BuildMI`` functions look like this:
388 // Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
389 // instruction. The '1' specifies how many operands will be added.
390 MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
392 // Create the same instr, but insert it at the end of a basic block.
393 MachineBasicBlock &MBB = ...
394 BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
396 // Create the same instr, but insert it before a specified iterator point.
397 MachineBasicBlock::iterator MBBI = ...
398 BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
400 // Create a 'cmp Reg, 0' instruction, no destination reg.
401 MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
403 // Create an 'sahf' instruction which takes no operands and stores nothing.
404 MI = BuildMI(X86::SAHF, 0);
406 // Create a self looping branch instruction.
407 BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
409 The key thing to remember with the ``BuildMI`` functions is that you have to
410 specify the number of operands that the machine instruction will take. This
411 allows for efficient memory allocation. You also need to specify if operands
412 default to be uses of values, not definitions. If you need to add a definition
413 operand (other than the optional destination register), you must explicitly mark
418 MI.addReg(Reg, RegState::Define);
420 Fixed (preassigned) registers
421 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
423 One important issue that the code generator needs to be aware of is the presence
424 of fixed registers. In particular, there are often places in the instruction
425 stream where the register allocator *must* arrange for a particular value to be
426 in a particular register. This can occur due to limitations of the instruction
427 set (e.g., the X86 can only do a 32-bit divide with the ``EAX``/``EDX``
428 registers), or external factors like calling conventions. In any case, the
429 instruction selector should emit code that copies a virtual register into or out
430 of a physical register when needed.
432 For example, consider this simple LLVM example:
436 define i32 @test(i32 %X, i32 %Y) {
441 The X86 instruction selector might produce this machine code for the ``div`` and
447 %EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX
448 %reg1027 = sar %reg1024, 31
449 %EDX = mov %reg1027 ;; Sign extend X into EDX
450 idiv %reg1025 ;; Divide by Y (in reg1025)
451 %reg1026 = mov %EAX ;; Read the result (Z) out of EAX
454 %EAX = mov %reg1026 ;; 32-bit return value goes in EAX
457 By the end of code generation, the register allocator would coalesce the
458 registers and delete the resultant identity moves producing the following
463 ;; X is in EAX, Y is in ECX
469 This approach is extremely general (if it can handle the X86 architecture, it
470 can handle anything!) and allows all of the target specific knowledge about the
471 instruction stream to be isolated in the instruction selector. Note that
472 physical registers should have a short lifetime for good code generation, and
473 all physical registers are assumed dead on entry to and exit from basic blocks
474 (before register allocation). Thus, if you need a value to be live across basic
475 block boundaries, it *must* live in a virtual register.
477 Call-clobbered registers
478 ^^^^^^^^^^^^^^^^^^^^^^^^
480 Some machine instructions, like calls, clobber a large number of physical
481 registers. Rather than adding ``<def,dead>`` operands for all of them, it is
482 possible to use an ``MO_RegisterMask`` operand instead. The register mask
483 operand holds a bit mask of preserved registers, and everything else is
484 considered to be clobbered by the instruction.
486 Machine code in SSA form
487 ^^^^^^^^^^^^^^^^^^^^^^^^
489 ``MachineInstr``'s are initially selected in SSA-form, and are maintained in
490 SSA-form until register allocation happens. For the most part, this is
491 trivially simple since LLVM is already in SSA form; LLVM PHI nodes become
492 machine code PHI nodes, and virtual registers are only allowed to have a single
495 After register allocation, machine code is no longer in SSA-form because there
496 are no virtual registers left in the code.
498 .. _MachineBasicBlock:
500 The ``MachineBasicBlock`` class
501 -------------------------------
503 The ``MachineBasicBlock`` class contains a list of machine instructions
504 (:raw-html:`<tt>` `MachineInstr`_ :raw-html:`</tt>` instances). It roughly
505 corresponds to the LLVM code input to the instruction selector, but there can be
506 a one-to-many mapping (i.e. one LLVM basic block can map to multiple machine
507 basic blocks). The ``MachineBasicBlock`` class has a "``getBasicBlock``" method,
508 which returns the LLVM basic block that it comes from.
512 The ``MachineFunction`` class
513 -----------------------------
515 The ``MachineFunction`` class contains a list of machine basic blocks
516 (:raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>` instances). It
517 corresponds one-to-one with the LLVM function input to the instruction selector.
518 In addition to a list of basic blocks, the ``MachineFunction`` contains a a
519 ``MachineConstantPool``, a ``MachineFrameInfo``, a ``MachineFunctionInfo``, and
520 a ``MachineRegisterInfo``. See ``include/llvm/CodeGen/MachineFunction.h`` for
523 ``MachineInstr Bundles``
524 ------------------------
526 LLVM code generator can model sequences of instructions as MachineInstr
527 bundles. A MI bundle can model a VLIW group / pack which contains an arbitrary
528 number of parallel instructions. It can also be used to model a sequential list
529 of instructions (potentially with data dependencies) that cannot be legally
530 separated (e.g. ARM Thumb2 IT blocks).
532 Conceptually a MI bundle is a MI with a number of other MIs nested within:
570 MI bundle support does not change the physical representations of
571 MachineBasicBlock and MachineInstr. All the MIs (including top level and nested
572 ones) are stored as sequential list of MIs. The "bundled" MIs are marked with
573 the 'InsideBundle' flag. A top level MI with the special BUNDLE opcode is used
574 to represent the start of a bundle. It's legal to mix BUNDLE MIs with indiviual
575 MIs that are not inside bundles nor represent bundles.
577 MachineInstr passes should operate on a MI bundle as a single unit. Member
578 methods have been taught to correctly handle bundles and MIs inside bundles.
579 The MachineBasicBlock iterator has been modified to skip over bundled MIs to
580 enforce the bundle-as-a-single-unit concept. An alternative iterator
581 instr_iterator has been added to MachineBasicBlock to allow passes to iterate
582 over all of the MIs in a MachineBasicBlock, including those which are nested
583 inside bundles. The top level BUNDLE instruction must have the correct set of
584 register MachineOperand's that represent the cumulative inputs and outputs of
587 Packing / bundling of MachineInstr's should be done as part of the register
588 allocation super-pass. More specifically, the pass which determines what MIs
589 should be bundled together must be done after code generator exits SSA form
590 (i.e. after two-address pass, PHI elimination, and copy coalescing). Bundles
591 should only be finalized (i.e. adding BUNDLE MIs and input and output register
592 MachineOperands) after virtual registers have been rewritten into physical
593 registers. This requirement eliminates the need to add virtual register operands
594 to BUNDLE instructions which would effectively double the virtual register def
602 The MC Layer is used to represent and process code at the raw machine code
603 level, devoid of "high level" information like "constant pools", "jump tables",
604 "global variables" or anything like that. At this level, LLVM handles things
605 like label names, machine instructions, and sections in the object file. The
606 code in this layer is used for a number of important purposes: the tail end of
607 the code generator uses it to write a .s or .o file, and it is also used by the
608 llvm-mc tool to implement standalone machine code assemblers and disassemblers.
610 This section describes some of the important classes. There are also a number
611 of important subsystems that interact at this layer, they are described later in
616 The ``MCStreamer`` API
617 ----------------------
619 MCStreamer is best thought of as an assembler API. It is an abstract API which
620 is *implemented* in different ways (e.g. to output a .s file, output an ELF .o
621 file, etc) but whose API correspond directly to what you see in a .s file.
622 MCStreamer has one method per directive, such as EmitLabel, EmitSymbolAttribute,
623 SwitchSection, EmitValue (for .byte, .word), etc, which directly correspond to
624 assembly level directives. It also has an EmitInstruction method, which is used
625 to output an MCInst to the streamer.
627 This API is most important for two clients: the llvm-mc stand-alone assembler is
628 effectively a parser that parses a line, then invokes a method on MCStreamer. In
629 the code generator, the `Code Emission`_ phase of the code generator lowers
630 higher level LLVM IR and Machine* constructs down to the MC layer, emitting
631 directives through MCStreamer.
633 On the implementation side of MCStreamer, there are two major implementations:
634 one for writing out a .s file (MCAsmStreamer), and one for writing out a .o
635 file (MCObjectStreamer). MCAsmStreamer is a straight-forward implementation
636 that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but
637 MCObjectStreamer implements a full assembler.
639 For target specific directives, the MCStreamer has a MCTargetStreamer instance.
640 Each target that needs it defines a class that inherits from it and is a lot
641 like MCStreamer itself: It has one method per directive and two classes that
642 inherit from it, a target object streamer and a target asm streamer. The target
643 asm streamer just prints it (``emitFnStart -> .fnstrart``), and the object
644 streamer implement the assembler logic for it.
646 To make llvm use these classes, the target initialization must call
647 TargetRegistry::RegisterAsmStreamer and TargetRegistry::RegisterMCObjectStreamer
648 passing callbacks that allocate the corresponding target streamer and pass it
649 to createAsmStreamer or to the appropriate object streamer constructor.
651 The ``MCContext`` class
652 -----------------------
654 The MCContext class is the owner of a variety of uniqued data structures at the
655 MC layer, including symbols, sections, etc. As such, this is the class that you
656 interact with to create symbols and sections. This class can not be subclassed.
658 The ``MCSymbol`` class
659 ----------------------
661 The MCSymbol class represents a symbol (aka label) in the assembly file. There
662 are two interesting kinds of symbols: assembler temporary symbols, and normal
663 symbols. Assembler temporary symbols are used and processed by the assembler
664 but are discarded when the object file is produced. The distinction is usually
665 represented by adding a prefix to the label, for example "L" labels are
666 assembler temporary labels in MachO.
668 MCSymbols are created by MCContext and uniqued there. This means that MCSymbols
669 can be compared for pointer equivalence to find out if they are the same symbol.
670 Note that pointer inequality does not guarantee the labels will end up at
671 different addresses though. It's perfectly legal to output something like this
680 In this case, both the foo and bar symbols will have the same address.
682 The ``MCSection`` class
683 -----------------------
685 The ``MCSection`` class represents an object-file specific section. It is
686 subclassed by object file specific implementations (e.g. ``MCSectionMachO``,
687 ``MCSectionCOFF``, ``MCSectionELF``) and these are created and uniqued by
688 MCContext. The MCStreamer has a notion of the current section, which can be
689 changed with the SwitchToSection method (which corresponds to a ".section"
690 directive in a .s file).
697 The ``MCInst`` class is a target-independent representation of an instruction.
698 It is a simple class (much more so than `MachineInstr`_) that holds a
699 target-specific opcode and a vector of MCOperands. MCOperand, in turn, is a
700 simple discriminated union of three cases: 1) a simple immediate, 2) a target
701 register ID, 3) a symbolic expression (e.g. "``Lfoo-Lbar+42``") as an MCExpr.
703 MCInst is the common currency used to represent machine instructions at the MC
704 layer. It is the type used by the instruction encoder, the instruction printer,
705 and the type generated by the assembly parser and disassembler.
707 .. _Target-independent algorithms:
708 .. _code generation algorithm:
710 Target-independent code generation algorithms
711 =============================================
713 This section documents the phases described in the `high-level design of the
714 code generator`_. It explains how they work and some of the rationale behind
717 .. _Instruction Selection:
718 .. _instruction selection section:
720 Instruction Selection
721 ---------------------
723 Instruction Selection is the process of translating LLVM code presented to the
724 code generator into target-specific machine instructions. There are several
725 well-known ways to do this in the literature. LLVM uses a SelectionDAG based
726 instruction selector.
728 Portions of the DAG instruction selector are generated from the target
729 description (``*.td``) files. Our goal is for the entire instruction selector
730 to be generated from these ``.td`` files, though currently there are still
731 things that require custom C++ code.
735 Introduction to SelectionDAGs
736 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
738 The SelectionDAG provides an abstraction for code representation in a way that
739 is amenable to instruction selection using automatic techniques
740 (e.g. dynamic-programming based optimal pattern matching selectors). It is also
741 well-suited to other phases of code generation; in particular, instruction
742 scheduling (SelectionDAG's are very close to scheduling DAGs post-selection).
743 Additionally, the SelectionDAG provides a host representation where a large
744 variety of very-low-level (but target-independent) `optimizations`_ may be
745 performed; ones which require extensive information about the instructions
746 efficiently supported by the target.
748 The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
749 ``SDNode`` class. The primary payload of the ``SDNode`` is its operation code
750 (Opcode) that indicates what operation the node performs and the operands to the
751 operation. The various operation node types are described at the top of the
752 ``include/llvm/CodeGen/SelectionDAGNodes.h`` file.
754 Although most operations define a single value, each node in the graph may
755 define multiple values. For example, a combined div/rem operation will define
756 both the dividend and the remainder. Many other situations require multiple
757 values as well. Each node also has some number of operands, which are edges to
758 the node defining the used value. Because nodes may define multiple values,
759 edges are represented by instances of the ``SDValue`` class, which is a
760 ``<SDNode, unsigned>`` pair, indicating the node and result value being used,
761 respectively. Each value produced by an ``SDNode`` has an associated ``MVT``
762 (Machine Value Type) indicating what the type of the value is.
764 SelectionDAGs contain two different kinds of values: those that represent data
765 flow and those that represent control flow dependencies. Data values are simple
766 edges with an integer or floating point value type. Control edges are
767 represented as "chain" edges which are of type ``MVT::Other``. These edges
768 provide an ordering between nodes that have side effects (such as loads, stores,
769 calls, returns, etc). All nodes that have side effects should take a token
770 chain as input and produce a new one as output. By convention, token chain
771 inputs are always operand #0, and chain results are always the last value
772 produced by an operation. However, after instruction selection, the
773 machine nodes have their chain after the instruction's operands, and
774 may be followed by glue nodes.
776 A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
777 always a marker node with an Opcode of ``ISD::EntryToken``. The Root node is
778 the final side-effecting node in the token chain. For example, in a single basic
779 block function it would be the return node.
781 One important concept for SelectionDAGs is the notion of a "legal" vs.
782 "illegal" DAG. A legal DAG for a target is one that only uses supported
783 operations and supported types. On a 32-bit PowerPC, for example, a DAG with a
784 value of type i1, i8, i16, or i64 would be illegal, as would a DAG that uses a
785 SREM or UREM operation. The `legalize types`_ and `legalize operations`_ phases
786 are responsible for turning an illegal DAG into a legal DAG.
788 .. _SelectionDAG-Process:
790 SelectionDAG Instruction Selection Process
791 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
793 SelectionDAG-based instruction selection consists of the following steps:
795 #. `Build initial DAG`_ --- This stage performs a simple translation from the
796 input LLVM code to an illegal SelectionDAG.
798 #. `Optimize SelectionDAG`_ --- This stage performs simple optimizations on the
799 SelectionDAG to simplify it, and recognize meta instructions (like rotates
800 and ``div``/``rem`` pairs) for targets that support these meta operations.
801 This makes the resultant code more efficient and the `select instructions
802 from DAG`_ phase (below) simpler.
804 #. `Legalize SelectionDAG Types`_ --- This stage transforms SelectionDAG nodes
805 to eliminate any types that are unsupported on the target.
807 #. `Optimize SelectionDAG`_ --- The SelectionDAG optimizer is run to clean up
808 redundancies exposed by type legalization.
810 #. `Legalize SelectionDAG Ops`_ --- This stage transforms SelectionDAG nodes to
811 eliminate any operations that are unsupported on the target.
813 #. `Optimize SelectionDAG`_ --- The SelectionDAG optimizer is run to eliminate
814 inefficiencies introduced by operation legalization.
816 #. `Select instructions from DAG`_ --- Finally, the target instruction selector
817 matches the DAG operations to target instructions. This process translates
818 the target-independent input DAG into another DAG of target instructions.
820 #. `SelectionDAG Scheduling and Formation`_ --- The last phase assigns a linear
821 order to the instructions in the target-instruction DAG and emits them into
822 the MachineFunction being compiled. This step uses traditional prepass
823 scheduling techniques.
825 After all of these steps are complete, the SelectionDAG is destroyed and the
826 rest of the code generation passes are run.
828 One great way to visualize what is going on here is to take advantage of a few
829 LLC command line options. The following options pop up a window displaying the
830 SelectionDAG at specific times (if you only get errors printed to the console
831 while using this, you probably `need to configure your
832 system <ProgrammersManual.html#ViewGraph>`_ to add support for it).
834 * ``-view-dag-combine1-dags`` displays the DAG after being built, before the
835 first optimization pass.
837 * ``-view-legalize-dags`` displays the DAG before Legalization.
839 * ``-view-dag-combine2-dags`` displays the DAG before the second optimization
842 * ``-view-isel-dags`` displays the DAG before the Select phase.
844 * ``-view-sched-dags`` displays the DAG before Scheduling.
846 The ``-view-sunit-dags`` displays the Scheduler's dependency graph. This graph
847 is based on the final SelectionDAG, with nodes that must be scheduled together
848 bundled into a single scheduling-unit node, and with immediate operands and
849 other nodes that aren't relevant for scheduling omitted.
851 .. _Build initial DAG:
853 Initial SelectionDAG Construction
854 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
856 The initial SelectionDAG is na\ :raw-html:`ï`\ vely peephole expanded from
857 the LLVM input by the ``SelectionDAGBuilder`` class. The intent of this pass
858 is to expose as much low-level, target-specific details to the SelectionDAG as
859 possible. This pass is mostly hard-coded (e.g. an LLVM ``add`` turns into an
860 ``SDNode add`` while a ``getelementptr`` is expanded into the obvious
861 arithmetic). This pass requires target-specific hooks to lower calls, returns,
862 varargs, etc. For these features, the :raw-html:`<tt>` `TargetLowering`_
863 :raw-html:`</tt>` interface is used.
866 .. _Legalize SelectionDAG Types:
867 .. _Legalize SelectionDAG Ops:
869 SelectionDAG LegalizeTypes Phase
870 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
872 The Legalize phase is in charge of converting a DAG to only use the types that
873 are natively supported by the target.
875 There are two main ways of converting values of unsupported scalar types to
876 values of supported types: converting small types to larger types ("promoting"),
877 and breaking up large integer types into smaller ones ("expanding"). For
878 example, a target might require that all f32 values are promoted to f64 and that
879 all i1/i8/i16 values are promoted to i32. The same target might require that
880 all i64 values be expanded into pairs of i32 values. These changes can insert
881 sign and zero extensions as needed to make sure that the final code has the same
882 behavior as the input.
884 There are two main ways of converting values of unsupported vector types to
885 value of supported types: splitting vector types, multiple times if necessary,
886 until a legal type is found, and extending vector types by adding elements to
887 the end to round them out to legal types ("widening"). If a vector gets split
888 all the way down to single-element parts with no supported vector type being
889 found, the elements are converted to scalars ("scalarizing").
891 A target implementation tells the legalizer which types are supported (and which
892 register class to use for them) by calling the ``addRegisterClass`` method in
893 its ``TargetLowering`` constructor.
895 .. _legalize operations:
898 SelectionDAG Legalize Phase
899 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
901 The Legalize phase is in charge of converting a DAG to only use the operations
902 that are natively supported by the target.
904 Targets often have weird constraints, such as not supporting every operation on
905 every supported datatype (e.g. X86 does not support byte conditional moves and
906 PowerPC does not support sign-extending loads from a 16-bit memory location).
907 Legalize takes care of this by open-coding another sequence of operations to
908 emulate the operation ("expansion"), by promoting one type to a larger type that
909 supports the operation ("promotion"), or by using a target-specific hook to
910 implement the legalization ("custom").
912 A target implementation tells the legalizer which operations are not supported
913 (and which of the above three actions to take) by calling the
914 ``setOperationAction`` method in its ``TargetLowering`` constructor.
916 Prior to the existence of the Legalize passes, we required that every target
917 `selector`_ supported and handled every operator and type even if they are not
918 natively supported. The introduction of the Legalize phases allows all of the
919 canonicalization patterns to be shared across targets, and makes it very easy to
920 optimize the canonicalized code because it is still in the form of a DAG.
923 .. _Optimize SelectionDAG:
926 SelectionDAG Optimization Phase: the DAG Combiner
927 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
929 The SelectionDAG optimization phase is run multiple times for code generation,
930 immediately after the DAG is built and once after each legalization. The first
931 run of the pass allows the initial code to be cleaned up (e.g. performing
932 optimizations that depend on knowing that the operators have restricted type
933 inputs). Subsequent runs of the pass clean up the messy code generated by the
934 Legalize passes, which allows Legalize to be very simple (it can focus on making
935 code legal instead of focusing on generating *good* and legal code).
937 One important class of optimizations performed is optimizing inserted sign and
938 zero extension instructions. We currently use ad-hoc techniques, but could move
939 to more rigorous techniques in the future. Here are some good papers on the
942 "`Widening integer arithmetic <http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html>`_" :raw-html:`<br>`
943 Kevin Redwine and Norman Ramsey :raw-html:`<br>`
944 International Conference on Compiler Construction (CC) 2004
946 "`Effective sign extension elimination <http://portal.acm.org/citation.cfm?doid=512529.512552>`_" :raw-html:`<br>`
947 Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani :raw-html:`<br>`
948 Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
951 .. _Select instructions from DAG:
953 SelectionDAG Select Phase
954 ^^^^^^^^^^^^^^^^^^^^^^^^^
956 The Select phase is the bulk of the target-specific code for instruction
957 selection. This phase takes a legal SelectionDAG as input, pattern matches the
958 instructions supported by the target to this DAG, and produces a new DAG of
959 target code. For example, consider the following LLVM fragment:
963 %t1 = fadd float %W, %X
964 %t2 = fmul float %t1, %Y
965 %t3 = fadd float %t2, %Z
967 This LLVM code corresponds to a SelectionDAG that looks basically like this:
971 (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
973 If a target supports floating point multiply-and-add (FMA) operations, one of
974 the adds can be merged with the multiply. On the PowerPC, for example, the
975 output of the instruction selector might look like this DAG:
979 (FMADDS (FADDS W, X), Y, Z)
981 The ``FMADDS`` instruction is a ternary instruction that multiplies its first
982 two operands and adds the third (as single-precision floating-point numbers).
983 The ``FADDS`` instruction is a simple binary single-precision add instruction.
984 To perform this pattern match, the PowerPC backend includes the following
985 instruction definitions:
988 :emphasize-lines: 4-5,9
990 def FMADDS : AForm_1<59, 29,
991 (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
992 "fmadds $FRT, $FRA, $FRC, $FRB",
993 [(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
995 def FADDS : AForm_2<59, 21,
996 (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
997 "fadds $FRT, $FRA, $FRB",
998 [(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))]>;
1000 The highlighted portion of the instruction definitions indicates the pattern
1001 used to match the instructions. The DAG operators (like ``fmul``/``fadd``)
1002 are defined in the ``include/llvm/Target/TargetSelectionDAG.td`` file.
1003 "``F4RC``" is the register class of the input and result values.
1005 The TableGen DAG instruction selector generator reads the instruction patterns
1006 in the ``.td`` file and automatically builds parts of the pattern matching code
1007 for your target. It has the following strengths:
1009 * At compiler-compiler time, it analyzes your instruction patterns and tells you
1010 if your patterns make sense or not.
1012 * It can handle arbitrary constraints on operands for the pattern match. In
1013 particular, it is straight-forward to say things like "match any immediate
1014 that is a 13-bit sign-extended value". For examples, see the ``immSExt16``
1015 and related ``tblgen`` classes in the PowerPC backend.
1017 * It knows several important identities for the patterns defined. For example,
1018 it knows that addition is commutative, so it allows the ``FMADDS`` pattern
1019 above to match "``(fadd X, (fmul Y, Z))``" as well as "``(fadd (fmul X, Y),
1020 Z)``", without the target author having to specially handle this case.
1022 * It has a full-featured type-inferencing system. In particular, you should
1023 rarely have to explicitly tell the system what type parts of your patterns
1024 are. In the ``FMADDS`` case above, we didn't have to tell ``tblgen`` that all
1025 of the nodes in the pattern are of type 'f32'. It was able to infer and
1026 propagate this knowledge from the fact that ``F4RC`` has type 'f32'.
1028 * Targets can define their own (and rely on built-in) "pattern fragments".
1029 Pattern fragments are chunks of reusable patterns that get inlined into your
1030 patterns during compiler-compiler time. For example, the integer "``(not
1031 x)``" operation is actually defined as a pattern fragment that expands as
1032 "``(xor x, -1)``", since the SelectionDAG does not have a native '``not``'
1033 operation. Targets can define their own short-hand fragments as they see fit.
1034 See the definition of '``not``' and '``ineg``' for examples.
1036 * In addition to instructions, targets can specify arbitrary patterns that map
1037 to one or more instructions using the 'Pat' class. For example, the PowerPC
1038 has no way to load an arbitrary integer immediate into a register in one
1039 instruction. To tell tblgen how to do this, it defines:
1043 // Arbitrary immediate support. Implement in terms of LIS/ORI.
1044 def : Pat<(i32 imm:$imm),
1045 (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;
1047 If none of the single-instruction patterns for loading an immediate into a
1048 register match, this will be used. This rule says "match an arbitrary i32
1049 immediate, turning it into an ``ORI`` ('or a 16-bit immediate') and an ``LIS``
1050 ('load 16-bit immediate, where the immediate is shifted to the left 16 bits')
1051 instruction". To make this work, the ``LO16``/``HI16`` node transformations
1052 are used to manipulate the input immediate (in this case, take the high or low
1053 16-bits of the immediate).
1055 * When using the 'Pat' class to map a pattern to an instruction that has one
1056 or more complex operands (like e.g. `X86 addressing mode`_), the pattern may
1057 either specify the operand as a whole using a ``ComplexPattern``, or else it
1058 may specify the components of the complex operand separately. The latter is
1059 done e.g. for pre-increment instructions by the PowerPC back end:
1063 def STWU : DForm_1<37, (outs ptr_rc:$ea_res), (ins GPRC:$rS, memri:$dst),
1064 "stwu $rS, $dst", LdStStoreUpd, []>,
1065 RegConstraint<"$dst.reg = $ea_res">, NoEncode<"$ea_res">;
1067 def : Pat<(pre_store GPRC:$rS, ptr_rc:$ptrreg, iaddroff:$ptroff),
1068 (STWU GPRC:$rS, iaddroff:$ptroff, ptr_rc:$ptrreg)>;
1070 Here, the pair of ``ptroff`` and ``ptrreg`` operands is matched onto the
1071 complex operand ``dst`` of class ``memri`` in the ``STWU`` instruction.
1073 * While the system does automate a lot, it still allows you to write custom C++
1074 code to match special cases if there is something that is hard to
1077 While it has many strengths, the system currently has some limitations,
1078 primarily because it is a work in progress and is not yet finished:
1080 * Overall, there is no way to define or match SelectionDAG nodes that define
1081 multiple values (e.g. ``SMUL_LOHI``, ``LOAD``, ``CALL``, etc). This is the
1082 biggest reason that you currently still *have to* write custom C++ code
1083 for your instruction selector.
1085 * There is no great way to support matching complex addressing modes yet. In
1086 the future, we will extend pattern fragments to allow them to define multiple
1087 values (e.g. the four operands of the `X86 addressing mode`_, which are
1088 currently matched with custom C++ code). In addition, we'll extend fragments
1089 so that a fragment can match multiple different patterns.
1091 * We don't automatically infer flags like ``isStore``/``isLoad`` yet.
1093 * We don't automatically generate the set of supported registers and operations
1094 for the `Legalizer`_ yet.
1096 * We don't have a way of tying in custom legalized nodes yet.
1098 Despite these limitations, the instruction selector generator is still quite
1099 useful for most of the binary and logical operations in typical instruction
1100 sets. If you run into any problems or can't figure out how to do something,
1101 please let Chris know!
1103 .. _Scheduling and Formation:
1104 .. _SelectionDAG Scheduling and Formation:
1106 SelectionDAG Scheduling and Formation Phase
1107 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1109 The scheduling phase takes the DAG of target instructions from the selection
1110 phase and assigns an order. The scheduler can pick an order depending on
1111 various constraints of the machines (i.e. order for minimal register pressure or
1112 try to cover instruction latencies). Once an order is established, the DAG is
1113 converted to a list of :raw-html:`<tt>` `MachineInstr`_\s :raw-html:`</tt>` and
1114 the SelectionDAG is destroyed.
1116 Note that this phase is logically separate from the instruction selection phase,
1117 but is tied to it closely in the code because it operates on SelectionDAGs.
1119 Future directions for the SelectionDAG
1120 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1122 #. Optional function-at-a-time selection.
1124 #. Auto-generate entire selector from ``.td`` file.
1126 .. _SSA-based Machine Code Optimizations:
1128 SSA-based Machine Code Optimizations
1129 ------------------------------------
1136 Live Intervals are the ranges (intervals) where a variable is *live*. They are
1137 used by some `register allocator`_ passes to determine if two or more virtual
1138 registers which require the same physical register are live at the same point in
1139 the program (i.e., they conflict). When this situation occurs, one virtual
1140 register must be *spilled*.
1142 Live Variable Analysis
1143 ^^^^^^^^^^^^^^^^^^^^^^
1145 The first step in determining the live intervals of variables is to calculate
1146 the set of registers that are immediately dead after the instruction (i.e., the
1147 instruction calculates the value, but it is never used) and the set of registers
1148 that are used by the instruction, but are never used after the instruction
1149 (i.e., they are killed). Live variable information is computed for
1150 each *virtual* register and *register allocatable* physical register
1151 in the function. This is done in a very efficient manner because it uses SSA to
1152 sparsely compute lifetime information for virtual registers (which are in SSA
1153 form) and only has to track physical registers within a block. Before register
1154 allocation, LLVM can assume that physical registers are only live within a
1155 single basic block. This allows it to do a single, local analysis to resolve
1156 physical register lifetimes within each basic block. If a physical register is
1157 not register allocatable (e.g., a stack pointer or condition codes), it is not
1160 Physical registers may be live in to or out of a function. Live in values are
1161 typically arguments in registers. Live out values are typically return values in
1162 registers. Live in values are marked as such, and are given a dummy "defining"
1163 instruction during live intervals analysis. If the last basic block of a
1164 function is a ``return``, then it's marked as using all live out values in the
1167 ``PHI`` nodes need to be handled specially, because the calculation of the live
1168 variable information from a depth first traversal of the CFG of the function
1169 won't guarantee that a virtual register used by the ``PHI`` node is defined
1170 before it's used. When a ``PHI`` node is encountered, only the definition is
1171 handled, because the uses will be handled in other basic blocks.
1173 For each ``PHI`` node of the current basic block, we simulate an assignment at
1174 the end of the current basic block and traverse the successor basic blocks. If a
1175 successor basic block has a ``PHI`` node and one of the ``PHI`` node's operands
1176 is coming from the current basic block, then the variable is marked as *alive*
1177 within the current basic block and all of its predecessor basic blocks, until
1178 the basic block with the defining instruction is encountered.
1180 Live Intervals Analysis
1181 ^^^^^^^^^^^^^^^^^^^^^^^
1183 We now have the information available to perform the live intervals analysis and
1184 build the live intervals themselves. We start off by numbering the basic blocks
1185 and machine instructions. We then handle the "live-in" values. These are in
1186 physical registers, so the physical register is assumed to be killed by the end
1187 of the basic block. Live intervals for virtual registers are computed for some
1188 ordering of the machine instructions ``[1, N]``. A live interval is an interval
1189 ``[i, j)``, where ``1 >= i >= j > N``, for which a variable is live.
1194 .. _Register Allocation:
1195 .. _register allocator:
1200 The *Register Allocation problem* consists in mapping a program
1201 :raw-html:`<b><tt>` P\ :sub:`v`\ :raw-html:`</tt></b>`, that can use an unbounded
1202 number of virtual registers, to a program :raw-html:`<b><tt>` P\ :sub:`p`\
1203 :raw-html:`</tt></b>` that contains a finite (possibly small) number of physical
1204 registers. Each target architecture has a different number of physical
1205 registers. If the number of physical registers is not enough to accommodate all
1206 the virtual registers, some of them will have to be mapped into memory. These
1207 virtuals are called *spilled virtuals*.
1209 How registers are represented in LLVM
1210 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1212 In LLVM, physical registers are denoted by integer numbers that normally range
1213 from 1 to 1023. To see how this numbering is defined for a particular
1214 architecture, you can read the ``GenRegisterNames.inc`` file for that
1215 architecture. For instance, by inspecting
1216 ``lib/Target/X86/X86GenRegisterInfo.inc`` we see that the 32-bit register
1217 ``EAX`` is denoted by 43, and the MMX register ``MM0`` is mapped to 65.
1219 Some architectures contain registers that share the same physical location. A
1220 notable example is the X86 platform. For instance, in the X86 architecture, the
1221 registers ``EAX``, ``AX`` and ``AL`` share the first eight bits. These physical
1222 registers are marked as *aliased* in LLVM. Given a particular architecture, you
1223 can check which registers are aliased by inspecting its ``RegisterInfo.td``
1224 file. Moreover, the class ``MCRegAliasIterator`` enumerates all the physical
1225 registers aliased to a register.
1227 Physical registers, in LLVM, are grouped in *Register Classes*. Elements in the
1228 same register class are functionally equivalent, and can be interchangeably
1229 used. Each virtual register can only be mapped to physical registers of a
1230 particular class. For instance, in the X86 architecture, some virtuals can only
1231 be allocated to 8 bit registers. A register class is described by
1232 ``TargetRegisterClass`` objects. To discover if a virtual register is
1233 compatible with a given physical, this code can be used:
1237 bool RegMapping_Fer::compatible_class(MachineFunction &mf,
1240 assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
1241 "Target register must be physical");
1242 const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
1243 return trc->contains(p_reg);
1246 Sometimes, mostly for debugging purposes, it is useful to change the number of
1247 physical registers available in the target architecture. This must be done
1248 statically, inside the ``TargetRegsterInfo.td`` file. Just ``grep`` for
1249 ``RegisterClass``, the last parameter of which is a list of registers. Just
1250 commenting some out is one simple way to avoid them being used. A more polite
1251 way is to explicitly exclude some registers from the *allocation order*. See the
1252 definition of the ``GR8`` register class in
1253 ``lib/Target/X86/X86RegisterInfo.td`` for an example of this.
1255 Virtual registers are also denoted by integer numbers. Contrary to physical
1256 registers, different virtual registers never share the same number. Whereas
1257 physical registers are statically defined in a ``TargetRegisterInfo.td`` file
1258 and cannot be created by the application developer, that is not the case with
1259 virtual registers. In order to create new virtual registers, use the method
1260 ``MachineRegisterInfo::createVirtualRegister()``. This method will return a new
1261 virtual register. Use an ``IndexedMap<Foo, VirtReg2IndexFunctor>`` to hold
1262 information per virtual register. If you need to enumerate all virtual
1263 registers, use the function ``TargetRegisterInfo::index2VirtReg()`` to find the
1264 virtual register numbers:
1268 for (unsigned i = 0, e = MRI->getNumVirtRegs(); i != e; ++i) {
1269 unsigned VirtReg = TargetRegisterInfo::index2VirtReg(i);
1273 Before register allocation, the operands of an instruction are mostly virtual
1274 registers, although physical registers may also be used. In order to check if a
1275 given machine operand is a register, use the boolean function
1276 ``MachineOperand::isRegister()``. To obtain the integer code of a register, use
1277 ``MachineOperand::getReg()``. An instruction may define or use a register. For
1278 instance, ``ADD reg:1026 := reg:1025 reg:1024`` defines the registers 1024, and
1279 uses registers 1025 and 1026. Given a register operand, the method
1280 ``MachineOperand::isUse()`` informs if that register is being used by the
1281 instruction. The method ``MachineOperand::isDef()`` informs if that registers is
1284 We will call physical registers present in the LLVM bitcode before register
1285 allocation *pre-colored registers*. Pre-colored registers are used in many
1286 different situations, for instance, to pass parameters of functions calls, and
1287 to store results of particular instructions. There are two types of pre-colored
1288 registers: the ones *implicitly* defined, and those *explicitly*
1289 defined. Explicitly defined registers are normal operands, and can be accessed
1290 with ``MachineInstr::getOperand(int)::getReg()``. In order to check which
1291 registers are implicitly defined by an instruction, use the
1292 ``TargetInstrInfo::get(opcode)::ImplicitDefs``, where ``opcode`` is the opcode
1293 of the target instruction. One important difference between explicit and
1294 implicit physical registers is that the latter are defined statically for each
1295 instruction, whereas the former may vary depending on the program being
1296 compiled. For example, an instruction that represents a function call will
1297 always implicitly define or use the same set of physical registers. To read the
1298 registers implicitly used by an instruction, use
1299 ``TargetInstrInfo::get(opcode)::ImplicitUses``. Pre-colored registers impose
1300 constraints on any register allocation algorithm. The register allocator must
1301 make sure that none of them are overwritten by the values of virtual registers
1304 Mapping virtual registers to physical registers
1305 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1307 There are two ways to map virtual registers to physical registers (or to memory
1308 slots). The first way, that we will call *direct mapping*, is based on the use
1309 of methods of the classes ``TargetRegisterInfo``, and ``MachineOperand``. The
1310 second way, that we will call *indirect mapping*, relies on the ``VirtRegMap``
1311 class in order to insert loads and stores sending and getting values to and from
1314 The direct mapping provides more flexibility to the developer of the register
1315 allocator; however, it is more error prone, and demands more implementation
1316 work. Basically, the programmer will have to specify where load and store
1317 instructions should be inserted in the target function being compiled in order
1318 to get and store values in memory. To assign a physical register to a virtual
1319 register present in a given operand, use ``MachineOperand::setReg(p_reg)``. To
1320 insert a store instruction, use ``TargetInstrInfo::storeRegToStackSlot(...)``,
1321 and to insert a load instruction, use ``TargetInstrInfo::loadRegFromStackSlot``.
1323 The indirect mapping shields the application developer from the complexities of
1324 inserting load and store instructions. In order to map a virtual register to a
1325 physical one, use ``VirtRegMap::assignVirt2Phys(vreg, preg)``. In order to map
1326 a certain virtual register to memory, use
1327 ``VirtRegMap::assignVirt2StackSlot(vreg)``. This method will return the stack
1328 slot where ``vreg``'s value will be located. If it is necessary to map another
1329 virtual register to the same stack slot, use
1330 ``VirtRegMap::assignVirt2StackSlot(vreg, stack_location)``. One important point
1331 to consider when using the indirect mapping, is that even if a virtual register
1332 is mapped to memory, it still needs to be mapped to a physical register. This
1333 physical register is the location where the virtual register is supposed to be
1334 found before being stored or after being reloaded.
1336 If the indirect strategy is used, after all the virtual registers have been
1337 mapped to physical registers or stack slots, it is necessary to use a spiller
1338 object to place load and store instructions in the code. Every virtual that has
1339 been mapped to a stack slot will be stored to memory after been defined and will
1340 be loaded before being used. The implementation of the spiller tries to recycle
1341 load/store instructions, avoiding unnecessary instructions. For an example of
1342 how to invoke the spiller, see ``RegAllocLinearScan::runOnMachineFunction`` in
1343 ``lib/CodeGen/RegAllocLinearScan.cpp``.
1345 Handling two address instructions
1346 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1348 With very rare exceptions (e.g., function calls), the LLVM machine code
1349 instructions are three address instructions. That is, each instruction is
1350 expected to define at most one register, and to use at most two registers.
1351 However, some architectures use two address instructions. In this case, the
1352 defined register is also one of the used register. For instance, an instruction
1353 such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX +
1356 In order to produce correct code, LLVM must convert three address instructions
1357 that represent two address instructions into true two address instructions. LLVM
1358 provides the pass ``TwoAddressInstructionPass`` for this specific purpose. It
1359 must be run before register allocation takes place. After its execution, the
1360 resulting code may no longer be in SSA form. This happens, for instance, in
1361 situations where an instruction such as ``%a = ADD %b %c`` is converted to two
1362 instructions such as:
1369 Notice that, internally, the second instruction is represented as ``ADD
1370 %a[def/use] %c``. I.e., the register operand ``%a`` is both used and defined by
1373 The SSA deconstruction phase
1374 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1376 An important transformation that happens during register allocation is called
1377 the *SSA Deconstruction Phase*. The SSA form simplifies many analyses that are
1378 performed on the control flow graph of programs. However, traditional
1379 instruction sets do not implement PHI instructions. Thus, in order to generate
1380 executable code, compilers must replace PHI instructions with other instructions
1381 that preserve their semantics.
1383 There are many ways in which PHI instructions can safely be removed from the
1384 target code. The most traditional PHI deconstruction algorithm replaces PHI
1385 instructions with copy instructions. That is the strategy adopted by LLVM. The
1386 SSA deconstruction algorithm is implemented in
1387 ``lib/CodeGen/PHIElimination.cpp``. In order to invoke this pass, the identifier
1388 ``PHIEliminationID`` must be marked as required in the code of the register
1394 *Instruction folding* is an optimization performed during register allocation
1395 that removes unnecessary copy instructions. For instance, a sequence of
1396 instructions such as:
1400 %EBX = LOAD %mem_address
1403 can be safely substituted by the single instruction:
1407 %EAX = LOAD %mem_address
1409 Instructions can be folded with the
1410 ``TargetRegisterInfo::foldMemoryOperand(...)`` method. Care must be taken when
1411 folding instructions; a folded instruction can be quite different from the
1412 original instruction. See ``LiveIntervals::addIntervalsForSpills`` in
1413 ``lib/CodeGen/LiveIntervalAnalysis.cpp`` for an example of its use.
1415 Built in register allocators
1416 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1418 The LLVM infrastructure provides the application developer with three different
1419 register allocators:
1421 * *Fast* --- This register allocator is the default for debug builds. It
1422 allocates registers on a basic block level, attempting to keep values in
1423 registers and reusing registers as appropriate.
1425 * *Basic* --- This is an incremental approach to register allocation. Live
1426 ranges are assigned to registers one at a time in an order that is driven by
1427 heuristics. Since code can be rewritten on-the-fly during allocation, this
1428 framework allows interesting allocators to be developed as extensions. It is
1429 not itself a production register allocator but is a potentially useful
1430 stand-alone mode for triaging bugs and as a performance baseline.
1432 * *Greedy* --- *The default allocator*. This is a highly tuned implementation of
1433 the *Basic* allocator that incorporates global live range splitting. This
1434 allocator works hard to minimize the cost of spill code.
1436 * *PBQP* --- A Partitioned Boolean Quadratic Programming (PBQP) based register
1437 allocator. This allocator works by constructing a PBQP problem representing
1438 the register allocation problem under consideration, solving this using a PBQP
1439 solver, and mapping the solution back to a register assignment.
1441 The type of register allocator used in ``llc`` can be chosen with the command
1442 line option ``-regalloc=...``:
1444 .. code-block:: bash
1446 $ llc -regalloc=linearscan file.bc -o ln.s
1447 $ llc -regalloc=fast file.bc -o fa.s
1448 $ llc -regalloc=pbqp file.bc -o pbqp.s
1450 .. _Prolog/Epilog Code Insertion:
1452 Prolog/Epilog Code Insertion
1453 ----------------------------
1457 Throwing an exception requires *unwinding* out of a function. The information on
1458 how to unwind a given function is traditionally expressed in DWARF unwind
1459 (a.k.a. frame) info. But that format was originally developed for debuggers to
1460 backtrace, and each Frame Description Entry (FDE) requires ~20-30 bytes per
1461 function. There is also the cost of mapping from an address in a function to the
1462 corresponding FDE at runtime. An alternative unwind encoding is called *compact
1463 unwind* and requires just 4-bytes per function.
1465 The compact unwind encoding is a 32-bit value, which is encoded in an
1466 architecture-specific way. It specifies which registers to restore and from
1467 where, and how to unwind out of the function. When the linker creates a final
1468 linked image, it will create a ``__TEXT,__unwind_info`` section. This section is
1469 a small and fast way for the runtime to access unwind info for any given
1470 function. If we emit compact unwind info for the function, that compact unwind
1471 info will be encoded in the ``__TEXT,__unwind_info`` section. If we emit DWARF
1472 unwind info, the ``__TEXT,__unwind_info`` section will contain the offset of the
1473 FDE in the ``__TEXT,__eh_frame`` section in the final linked image.
1475 For X86, there are three modes for the compact unwind encoding:
1477 *Function with a Frame Pointer (``EBP`` or ``RBP``)*
1478 ``EBP/RBP``-based frame, where ``EBP/RBP`` is pushed onto the stack
1479 immediately after the return address, then ``ESP/RSP`` is moved to
1480 ``EBP/RBP``. Thus to unwind, ``ESP/RSP`` is restored with the current
1481 ``EBP/RBP`` value, then ``EBP/RBP`` is restored by popping the stack, and the
1482 return is done by popping the stack once more into the PC. All non-volatile
1483 registers that need to be restored must have been saved in a small range on
1484 the stack that starts ``EBP-4`` to ``EBP-1020`` (``RBP-8`` to
1485 ``RBP-1020``). The offset (divided by 4 in 32-bit mode and 8 in 64-bit mode)
1486 is encoded in bits 16-23 (mask: ``0x00FF0000``). The registers saved are
1487 encoded in bits 0-14 (mask: ``0x00007FFF``) as five 3-bit entries from the
1490 ============== ============= ===============
1491 Compact Number i386 Register x86-64 Register
1492 ============== ============= ===============
1499 ============== ============= ===============
1501 *Frameless with a Small Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)*
1502 To return, a constant (encoded in the compact unwind encoding) is added to the
1503 ``ESP/RSP``. Then the return is done by popping the stack into the PC. All
1504 non-volatile registers that need to be restored must have been saved on the
1505 stack immediately after the return address. The stack size (divided by 4 in
1506 32-bit mode and 8 in 64-bit mode) is encoded in bits 16-23 (mask:
1507 ``0x00FF0000``). There is a maximum stack size of 1024 bytes in 32-bit mode
1508 and 2048 in 64-bit mode. The number of registers saved is encoded in bits 9-12
1509 (mask: ``0x00001C00``). Bits 0-9 (mask: ``0x000003FF``) contain which
1510 registers were saved and their order. (See the
1511 ``encodeCompactUnwindRegistersWithoutFrame()`` function in
1512 ``lib/Target/X86FrameLowering.cpp`` for the encoding algorithm.)
1514 *Frameless with a Large Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)*
1515 This case is like the "Frameless with a Small Constant Stack Size" case, but
1516 the stack size is too large to encode in the compact unwind encoding. Instead
1517 it requires that the function contains "``subl $nnnnnn, %esp``" in its
1518 prolog. The compact encoding contains the offset to the ``$nnnnnn`` value in
1519 the function in bits 9-12 (mask: ``0x00001C00``).
1521 .. _Late Machine Code Optimizations:
1523 Late Machine Code Optimizations
1524 -------------------------------
1535 The code emission step of code generation is responsible for lowering from the
1536 code generator abstractions (like `MachineFunction`_, `MachineInstr`_, etc) down
1537 to the abstractions used by the MC layer (`MCInst`_, `MCStreamer`_, etc). This
1538 is done with a combination of several different classes: the (misnamed)
1539 target-independent AsmPrinter class, target-specific subclasses of AsmPrinter
1540 (such as SparcAsmPrinter), and the TargetLoweringObjectFile class.
1542 Since the MC layer works at the level of abstraction of object files, it doesn't
1543 have a notion of functions, global variables etc. Instead, it thinks about
1544 labels, directives, and instructions. A key class used at this time is the
1545 MCStreamer class. This is an abstract API that is implemented in different ways
1546 (e.g. to output a .s file, output an ELF .o file, etc) that is effectively an
1547 "assembler API". MCStreamer has one method per directive, such as EmitLabel,
1548 EmitSymbolAttribute, SwitchSection, etc, which directly correspond to assembly
1551 If you are interested in implementing a code generator for a target, there are
1552 three important things that you have to implement for your target:
1554 #. First, you need a subclass of AsmPrinter for your target. This class
1555 implements the general lowering process converting MachineFunction's into MC
1556 label constructs. The AsmPrinter base class provides a number of useful
1557 methods and routines, and also allows you to override the lowering process in
1558 some important ways. You should get much of the lowering for free if you are
1559 implementing an ELF, COFF, or MachO target, because the
1560 TargetLoweringObjectFile class implements much of the common logic.
1562 #. Second, you need to implement an instruction printer for your target. The
1563 instruction printer takes an `MCInst`_ and renders it to a raw_ostream as
1564 text. Most of this is automatically generated from the .td file (when you
1565 specify something like "``add $dst, $src1, $src2``" in the instructions), but
1566 you need to implement routines to print operands.
1568 #. Third, you need to implement code that lowers a `MachineInstr`_ to an MCInst,
1569 usually implemented in "<target>MCInstLower.cpp". This lowering process is
1570 often target specific, and is responsible for turning jump table entries,
1571 constant pool indices, global variable addresses, etc into MCLabels as
1572 appropriate. This translation layer is also responsible for expanding pseudo
1573 ops used by the code generator into the actual machine instructions they
1574 correspond to. The MCInsts that are generated by this are fed into the
1575 instruction printer or the encoder.
1577 Finally, at your choosing, you can also implement an subclass of MCCodeEmitter
1578 which lowers MCInst's into machine code bytes and relocations. This is
1579 important if you want to support direct .o file emission, or would like to
1580 implement an assembler for your target.
1585 In a Very Long Instruction Word (VLIW) architecture, the compiler is responsible
1586 for mapping instructions to functional-units available on the architecture. To
1587 that end, the compiler creates groups of instructions called *packets* or
1588 *bundles*. The VLIW packetizer in LLVM is a target-independent mechanism to
1589 enable the packetization of machine instructions.
1591 Mapping from instructions to functional units
1592 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1594 Instructions in a VLIW target can typically be mapped to multiple functional
1595 units. During the process of packetizing, the compiler must be able to reason
1596 about whether an instruction can be added to a packet. This decision can be
1597 complex since the compiler has to examine all possible mappings of instructions
1598 to functional units. Therefore to alleviate compilation-time complexity, the
1599 VLIW packetizer parses the instruction classes of a target and generates tables
1600 at compiler build time. These tables can then be queried by the provided
1601 machine-independent API to determine if an instruction can be accommodated in a
1604 How the packetization tables are generated and used
1605 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1607 The packetizer reads instruction classes from a target's itineraries and creates
1608 a deterministic finite automaton (DFA) to represent the state of a packet. A DFA
1609 consists of three major elements: inputs, states, and transitions. The set of
1610 inputs for the generated DFA represents the instruction being added to a
1611 packet. The states represent the possible consumption of functional units by
1612 instructions in a packet. In the DFA, transitions from one state to another
1613 occur on the addition of an instruction to an existing packet. If there is a
1614 legal mapping of functional units to instructions, then the DFA contains a
1615 corresponding transition. The absence of a transition indicates that a legal
1616 mapping does not exist and that the instruction cannot be added to the packet.
1618 To generate tables for a VLIW target, add *Target*\ GenDFAPacketizer.inc as a
1619 target to the Makefile in the target directory. The exported API provides three
1620 functions: ``DFAPacketizer::clearResources()``,
1621 ``DFAPacketizer::reserveResources(MachineInstr *MI)``, and
1622 ``DFAPacketizer::canReserveResources(MachineInstr *MI)``. These functions allow
1623 a target packetizer to add an instruction to an existing packet and to check
1624 whether an instruction can be added to a packet. See
1625 ``llvm/CodeGen/DFAPacketizer.h`` for more information.
1627 Implementing a Native Assembler
1628 ===============================
1630 Though you're probably reading this because you want to write or maintain a
1631 compiler backend, LLVM also fully supports building a native assembler.
1632 We've tried hard to automate the generation of the assembler from the .td files
1633 (in particular the instruction syntax and encodings), which means that a large
1634 part of the manual and repetitive data entry can be factored and shared with the
1645 Instruction Alias Processing
1646 ----------------------------
1648 Once the instruction is parsed, it enters the MatchInstructionImpl function.
1649 The MatchInstructionImpl function performs alias processing and then does actual
1652 Alias processing is the phase that canonicalizes different lexical forms of the
1653 same instructions down to one representation. There are several different kinds
1654 of alias that are possible to implement and they are listed below in the order
1655 that they are processed (which is in order from simplest/weakest to most
1656 complex/powerful). Generally you want to use the first alias mechanism that
1657 meets the needs of your instruction, because it will allow a more concise
1663 The first phase of alias processing is simple instruction mnemonic remapping for
1664 classes of instructions which are allowed with two different mnemonics. This
1665 phase is a simple and unconditionally remapping from one input mnemonic to one
1666 output mnemonic. It isn't possible for this form of alias to look at the
1667 operands at all, so the remapping must apply for all forms of a given mnemonic.
1668 Mnemonic aliases are defined simply, for example X86 has:
1672 def : MnemonicAlias<"cbw", "cbtw">;
1673 def : MnemonicAlias<"smovq", "movsq">;
1674 def : MnemonicAlias<"fldcww", "fldcw">;
1675 def : MnemonicAlias<"fucompi", "fucomip">;
1676 def : MnemonicAlias<"ud2a", "ud2">;
1678 ... and many others. With a MnemonicAlias definition, the mnemonic is remapped
1679 simply and directly. Though MnemonicAlias's can't look at any aspect of the
1680 instruction (such as the operands) they can depend on global modes (the same
1681 ones supported by the matcher), through a Requires clause:
1685 def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
1686 def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;
1688 In this example, the mnemonic gets mapped into a different one depending on
1689 the current instruction set.
1694 The most general phase of alias processing occurs while matching is happening:
1695 it provides new forms for the matcher to match along with a specific instruction
1696 to generate. An instruction alias has two parts: the string to match and the
1697 instruction to generate. For example:
1701 def : InstAlias<"movsx $src, $dst", (MOVSX16rr8W GR16:$dst, GR8 :$src)>;
1702 def : InstAlias<"movsx $src, $dst", (MOVSX16rm8W GR16:$dst, i8mem:$src)>;
1703 def : InstAlias<"movsx $src, $dst", (MOVSX32rr8 GR32:$dst, GR8 :$src)>;
1704 def : InstAlias<"movsx $src, $dst", (MOVSX32rr16 GR32:$dst, GR16 :$src)>;
1705 def : InstAlias<"movsx $src, $dst", (MOVSX64rr8 GR64:$dst, GR8 :$src)>;
1706 def : InstAlias<"movsx $src, $dst", (MOVSX64rr16 GR64:$dst, GR16 :$src)>;
1707 def : InstAlias<"movsx $src, $dst", (MOVSX64rr32 GR64:$dst, GR32 :$src)>;
1709 This shows a powerful example of the instruction aliases, matching the same
1710 mnemonic in multiple different ways depending on what operands are present in
1711 the assembly. The result of instruction aliases can include operands in a
1712 different order than the destination instruction, and can use an input multiple
1717 def : InstAlias<"clrb $reg", (XOR8rr GR8 :$reg, GR8 :$reg)>;
1718 def : InstAlias<"clrw $reg", (XOR16rr GR16:$reg, GR16:$reg)>;
1719 def : InstAlias<"clrl $reg", (XOR32rr GR32:$reg, GR32:$reg)>;
1720 def : InstAlias<"clrq $reg", (XOR64rr GR64:$reg, GR64:$reg)>;
1722 This example also shows that tied operands are only listed once. In the X86
1723 backend, XOR8rr has two input GR8's and one output GR8 (where an input is tied
1724 to the output). InstAliases take a flattened operand list without duplicates
1725 for tied operands. The result of an instruction alias can also use immediates
1726 and fixed physical registers which are added as simple immediate operands in the
1727 result, for example:
1731 // Fixed Immediate operand.
1732 def : InstAlias<"aad", (AAD8i8 10)>;
1734 // Fixed register operand.
1735 def : InstAlias<"fcomi", (COM_FIr ST1)>;
1738 def : InstAlias<"fcomi $reg", (COM_FIr RST:$reg)>;
1740 Instruction aliases can also have a Requires clause to make them subtarget
1743 If the back-end supports it, the instruction printer can automatically emit the
1744 alias rather than what's being aliased. It typically leads to better, more
1745 readable code. If it's better to print out what's being aliased, then pass a '0'
1746 as the third parameter to the InstAlias definition.
1748 Instruction Matching
1749 --------------------
1755 .. _Implementations of the abstract target description interfaces:
1756 .. _implement the target description:
1758 Target-specific Implementation Notes
1759 ====================================
1761 This section of the document explains features or design decisions that are
1762 specific to the code generator for a particular target. First we start with a
1763 table that summarizes what features are supported by each target.
1765 .. _target-feature-matrix:
1767 Target Feature Matrix
1768 ---------------------
1770 Note that this table does not include the C backend or Cpp backends, since they
1771 do not use the target independent code generator infrastructure. It also
1772 doesn't list features that are not supported fully by any target yet. It
1773 considers a feature to be supported if at least one subtarget supports it. A
1774 feature being supported means that it is useful and works for most cases, it
1775 does not indicate that there are zero known bugs in the implementation. Here is
1778 :raw-html:`<table border="1" cellspacing="0">`
1780 :raw-html:`<th>Unknown</th>`
1781 :raw-html:`<th>Not Applicable</th>`
1782 :raw-html:`<th>No support</th>`
1783 :raw-html:`<th>Partial Support</th>`
1784 :raw-html:`<th>Complete Support</th>`
1787 :raw-html:`<td class="unknown"></td>`
1788 :raw-html:`<td class="na"></td>`
1789 :raw-html:`<td class="no"></td>`
1790 :raw-html:`<td class="partial"></td>`
1791 :raw-html:`<td class="yes"></td>`
1793 :raw-html:`</table>`
1797 :raw-html:`<table width="689" border="1" cellspacing="0">`
1798 :raw-html:`<tr><td></td>`
1799 :raw-html:`<td colspan="13" align="center" style="background-color:#ffc">Target</td>`
1802 :raw-html:`<th>Feature</th>`
1803 :raw-html:`<th>ARM</th>`
1804 :raw-html:`<th>Hexagon</th>`
1805 :raw-html:`<th>MSP430</th>`
1806 :raw-html:`<th>Mips</th>`
1807 :raw-html:`<th>NVPTX</th>`
1808 :raw-html:`<th>PowerPC</th>`
1809 :raw-html:`<th>Sparc</th>`
1810 :raw-html:`<th>SystemZ</th>`
1811 :raw-html:`<th>X86</th>`
1812 :raw-html:`<th>XCore</th>`
1816 :raw-html:`<td><a href="#feat_reliable">is generally reliable</a></td>`
1817 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1818 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
1819 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1820 :raw-html:`<td class="yes"></td> <!-- Mips -->`
1821 :raw-html:`<td class="yes"></td> <!-- NVPTX -->`
1822 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1823 :raw-html:`<td class="yes"></td> <!-- Sparc -->`
1824 :raw-html:`<td class="yes"></td> <!-- SystemZ -->`
1825 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1826 :raw-html:`<td class="yes"></td> <!-- XCore -->`
1830 :raw-html:`<td><a href="#feat_asmparser">assembly parser</a></td>`
1831 :raw-html:`<td class="no"></td> <!-- ARM -->`
1832 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1833 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1834 :raw-html:`<td class="no"></td> <!-- Mips -->`
1835 :raw-html:`<td class="no"></td> <!-- NVPTX -->`
1836 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1837 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1838 :raw-html:`<td class="yes"></td> <!-- SystemZ -->`
1839 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1840 :raw-html:`<td class="no"></td> <!-- XCore -->`
1844 :raw-html:`<td><a href="#feat_disassembler">disassembler</a></td>`
1845 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1846 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1847 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1848 :raw-html:`<td class="no"></td> <!-- Mips -->`
1849 :raw-html:`<td class="na"></td> <!-- NVPTX -->`
1850 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1851 :raw-html:`<td class="yes"></td> <!-- SystemZ -->`
1852 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1853 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1854 :raw-html:`<td class="yes"></td> <!-- XCore -->`
1858 :raw-html:`<td><a href="#feat_inlineasm">inline asm</a></td>`
1859 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1860 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
1861 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1862 :raw-html:`<td class="no"></td> <!-- Mips -->`
1863 :raw-html:`<td class="yes"></td> <!-- NVPTX -->`
1864 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1865 :raw-html:`<td class="unknown"></td> <!-- Sparc -->`
1866 :raw-html:`<td class="yes"></td> <!-- SystemZ -->`
1867 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1868 :raw-html:`<td class="yes"></td> <!-- XCore -->`
1872 :raw-html:`<td><a href="#feat_jit">jit</a></td>`
1873 :raw-html:`<td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->`
1874 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1875 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1876 :raw-html:`<td class="yes"></td> <!-- Mips -->`
1877 :raw-html:`<td class="na"></td> <!-- NVPTX -->`
1878 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1879 :raw-html:`<td class="unknown"></td> <!-- Sparc -->`
1880 :raw-html:`<td class="yes"></td> <!-- SystemZ -->`
1881 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1882 :raw-html:`<td class="no"></td> <!-- XCore -->`
1886 :raw-html:`<td><a href="#feat_objectwrite">.o file writing</a></td>`
1887 :raw-html:`<td class="no"></td> <!-- ARM -->`
1888 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1889 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1890 :raw-html:`<td class="no"></td> <!-- Mips -->`
1891 :raw-html:`<td class="na"></td> <!-- NVPTX -->`
1892 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1893 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1894 :raw-html:`<td class="yes"></td> <!-- SystemZ -->`
1895 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1896 :raw-html:`<td class="no"></td> <!-- XCore -->`
1900 :raw-html:`<td><a hr:raw-html:`ef="#feat_tailcall">tail calls</a></td>`
1901 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1902 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
1903 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1904 :raw-html:`<td class="no"></td> <!-- Mips -->`
1905 :raw-html:`<td class="no"></td> <!-- NVPTX -->`
1906 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1907 :raw-html:`<td class="unknown"></td> <!-- Sparc -->`
1908 :raw-html:`<td class="no"></td> <!-- SystemZ -->`
1909 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1910 :raw-html:`<td class="no"></td> <!-- XCore -->`
1914 :raw-html:`<td><a href="#feat_segstacks">segmented stacks</a></td>`
1915 :raw-html:`<td class="no"></td> <!-- ARM -->`
1916 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1917 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1918 :raw-html:`<td class="no"></td> <!-- Mips -->`
1919 :raw-html:`<td class="no"></td> <!-- NVPTX -->`
1920 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1921 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1922 :raw-html:`<td class="no"></td> <!-- SystemZ -->`
1923 :raw-html:`<td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 -->`
1924 :raw-html:`<td class="no"></td> <!-- XCore -->`
1927 :raw-html:`</table>`
1931 Is Generally Reliable
1932 ^^^^^^^^^^^^^^^^^^^^^
1934 This box indicates whether the target is considered to be production quality.
1935 This indicates that the target has been used as a static compiler to compile
1936 large amounts of code by a variety of different people and is in continuous use.
1943 This box indicates whether the target supports parsing target specific .s files
1944 by implementing the MCAsmParser interface. This is required for llvm-mc to be
1945 able to act as a native assembler and is required for inline assembly support in
1946 the native .o file writer.
1948 .. _feat_disassembler:
1953 This box indicates whether the target supports the MCDisassembler API for
1954 disassembling machine opcode bytes into MCInst's.
1961 This box indicates whether the target supports most popular inline assembly
1962 constraints and modifiers.
1969 This box indicates whether the target supports the JIT compiler through the
1970 ExecutionEngine interface.
1974 The ARM backend has basic support for integer code in ARM codegen mode, but
1975 lacks NEON and full Thumb support.
1977 .. _feat_objectwrite:
1982 This box indicates whether the target supports writing .o files (e.g. MachO,
1983 ELF, and/or COFF) files directly from the target. Note that the target also
1984 must include an assembly parser and general inline assembly support for full
1985 inline assembly support in the .o writer.
1987 Targets that don't support this feature can obviously still write out .o files,
1988 they just rely on having an external assembler to translate from a .s file to a
1989 .o file (as is the case for many C compilers).
1996 This box indicates whether the target supports guaranteed tail calls. These are
1997 calls marked "`tail <LangRef.html#i_call>`_" and use the fastcc calling
1998 convention. Please see the `tail call section`_ for more details.
2005 This box indicates whether the target supports segmented stacks. This replaces
2006 the traditional large C stack with many linked segments. It is compatible with
2007 the `gcc implementation <http://gcc.gnu.org/wiki/SplitStacks>`_ used by the Go
2010 .. _feat_segstacks_x86:
2012 Basic support exists on the X86 backend. Currently vararg doesn't work and the
2013 object files are not marked the way the gold linker expects, but simple Go
2014 programs can be built by dragonegg.
2016 .. _tail call section:
2018 Tail call optimization
2019 ----------------------
2021 Tail call optimization, callee reusing the stack of the caller, is currently
2022 supported on x86/x86-64 and PowerPC. It is performed if:
2024 * Caller and callee have the calling convention ``fastcc``, ``cc 10`` (GHC
2025 calling convention) or ``cc 11`` (HiPE calling convention).
2027 * The call is a tail call - in tail position (ret immediately follows call and
2028 ret uses value of call or is void).
2030 * Option ``-tailcallopt`` is enabled.
2032 * Platform-specific constraints are met.
2034 x86/x86-64 constraints:
2036 * No variable argument lists are used.
2038 * On x86-64 when generating GOT/PIC code only module-local calls (visibility =
2039 hidden or protected) are supported.
2041 PowerPC constraints:
2043 * No variable argument lists are used.
2045 * No byval parameters are used.
2047 * On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected)
2052 Call as ``llc -tailcallopt test.ll``.
2054 .. code-block:: llvm
2056 declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
2058 define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
2059 %l1 = add i32 %in1, %in2
2060 %tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
2064 Implications of ``-tailcallopt``:
2066 To support tail call optimization in situations where the callee has more
2067 arguments than the caller a 'callee pops arguments' convention is used. This
2068 currently causes each ``fastcc`` call that is not tail call optimized (because
2069 one or more of above constraints are not met) to be followed by a readjustment
2070 of the stack. So performance might be worse in such cases.
2072 Sibling call optimization
2073 -------------------------
2075 Sibling call optimization is a restricted form of tail call optimization.
2076 Unlike tail call optimization described in the previous section, it can be
2077 performed automatically on any tail calls when ``-tailcallopt`` option is not
2080 Sibling call optimization is currently performed on x86/x86-64 when the
2081 following constraints are met:
2083 * Caller and callee have the same calling convention. It can be either ``c`` or
2086 * The call is a tail call - in tail position (ret immediately follows call and
2087 ret uses value of call or is void).
2089 * Caller and callee have matching return type or the callee result is not used.
2091 * If any of the callee arguments are being passed in stack, they must be
2092 available in caller's own incoming argument stack and the frame offsets must
2097 .. code-block:: llvm
2099 declare i32 @bar(i32, i32)
2101 define i32 @foo(i32 %a, i32 %b, i32 %c) {
2103 %0 = tail call i32 @bar(i32 %a, i32 %b)
2110 The X86 code generator lives in the ``lib/Target/X86`` directory. This code
2111 generator is capable of targeting a variety of x86-32 and x86-64 processors, and
2112 includes support for ISA extensions such as MMX and SSE.
2114 X86 Target Triples supported
2115 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2117 The following are the known target triples that are supported by the X86
2118 backend. This is not an exhaustive list, and it would be useful to add those
2121 * **i686-pc-linux-gnu** --- Linux
2123 * **i386-unknown-freebsd5.3** --- FreeBSD 5.3
2125 * **i686-pc-cygwin** --- Cygwin on Win32
2127 * **i686-pc-mingw32** --- MingW on Win32
2129 * **i386-pc-mingw32msvc** --- MingW crosscompiler on Linux
2131 * **i686-apple-darwin*** --- Apple Darwin on X86
2133 * **x86_64-unknown-linux-gnu** --- Linux
2135 X86 Calling Conventions supported
2136 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2138 The following target-specific calling conventions are known to backend:
2140 * **x86_StdCall** --- stdcall calling convention seen on Microsoft Windows
2141 platform (CC ID = 64).
2143 * **x86_FastCall** --- fastcall calling convention seen on Microsoft Windows
2144 platform (CC ID = 65).
2146 * **x86_ThisCall** --- Similar to X86_StdCall. Passes first argument in ECX,
2147 others via stack. Callee is responsible for stack cleaning. This convention is
2148 used by MSVC by default for methods in its ABI (CC ID = 70).
2150 .. _X86 addressing mode:
2152 Representing X86 addressing modes in MachineInstrs
2153 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2155 The x86 has a very flexible way of accessing memory. It is capable of forming
2156 memory addresses of the following expression directly in integer instructions
2157 (which use ModR/M addressing):
2161 SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32
2163 In order to represent this, LLVM tracks no less than 5 operands for each memory
2164 operand of this form. This means that the "load" form of '``mov``' has the
2165 following ``MachineOperand``\s in this order:
2169 Index: 0 | 1 2 3 4 5
2170 Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement Segment
2171 OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg
2173 Stores, and all other instructions, treat the four memory operands in the same
2174 way and in the same order. If the segment register is unspecified (regno = 0),
2175 then no segment override is generated. "Lea" operations do not have a segment
2176 register specified, so they only have 4 operands for their memory reference.
2178 X86 address spaces supported
2179 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2181 x86 has a feature which provides the ability to perform loads and stores to
2182 different address spaces via the x86 segment registers. A segment override
2183 prefix byte on an instruction causes the instruction's memory access to go to
2184 the specified segment. LLVM address space 0 is the default address space, which
2185 includes the stack, and any unqualified memory accesses in a program. Address
2186 spaces 1-255 are currently reserved for user-defined code. The GS-segment is
2187 represented by address space 256, while the FS-segment is represented by address
2188 space 257. Other x86 segments have yet to be allocated address space
2191 While these address spaces may seem similar to TLS via the ``thread_local``
2192 keyword, and often use the same underlying hardware, there are some fundamental
2195 The ``thread_local`` keyword applies to global variables and specifies that they
2196 are to be allocated in thread-local memory. There are no type qualifiers
2197 involved, and these variables can be pointed to with normal pointers and
2198 accessed with normal loads and stores. The ``thread_local`` keyword is
2199 target-independent at the LLVM IR level (though LLVM doesn't yet have
2200 implementations of it for some configurations)
2202 Special address spaces, in contrast, apply to static types. Every load and store
2203 has a particular address space in its address operand type, and this is what
2204 determines which address space is accessed. LLVM ignores these special address
2205 space qualifiers on global variables, and does not provide a way to directly
2206 allocate storage in them. At the LLVM IR level, the behavior of these special
2207 address spaces depends in part on the underlying OS or runtime environment, and
2208 they are specific to x86 (and LLVM doesn't yet handle them correctly in some
2211 Some operating systems and runtime environments use (or may in the future use)
2212 the FS/GS-segment registers for various low-level purposes, so care should be
2213 taken when considering them.
2218 An instruction name consists of the base name, a default operand size, and a a
2219 character per operand with an optional special size. For example:
2223 ADD8rr -> add, 8-bit register, 8-bit register
2224 IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
2225 IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
2226 MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
2231 The PowerPC code generator lives in the lib/Target/PowerPC directory. The code
2232 generation is retargetable to several variations or *subtargets* of the PowerPC
2233 ISA; including ppc32, ppc64 and altivec.
2238 LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC relative
2239 (PIC) or static addressing for accessing global values, so no TOC (r2) is
2240 used. Second, r31 is used as a frame pointer to allow dynamic growth of a stack
2241 frame. LLVM takes advantage of having no TOC to provide space to save the frame
2242 pointer in the PowerPC linkage area of the caller frame. Other details of
2243 PowerPC ABI can be found at `PowerPC ABI
2244 <http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html>`_\
2245 . Note: This link describes the 32 bit ABI. The 64 bit ABI is similar except
2246 space for GPRs are 8 bytes wide (not 4) and r13 is reserved for system use.
2251 The size of a PowerPC frame is usually fixed for the duration of a function's
2252 invocation. Since the frame is fixed size, all references into the frame can be
2253 accessed via fixed offsets from the stack pointer. The exception to this is
2254 when dynamic alloca or variable sized arrays are present, then a base pointer
2255 (r31) is used as a proxy for the stack pointer and stack pointer is free to grow
2256 or shrink. A base pointer is also used if llvm-gcc is not passed the
2257 -fomit-frame-pointer flag. The stack pointer is always aligned to 16 bytes, so
2258 that space allocated for altivec vectors will be properly aligned.
2260 An invocation frame is laid out as follows (low memory at top):
2262 :raw-html:`<table border="1" cellspacing="0">`
2264 :raw-html:`<td>Linkage<br><br></td>`
2267 :raw-html:`<td>Parameter area<br><br></td>`
2270 :raw-html:`<td>Dynamic area<br><br></td>`
2273 :raw-html:`<td>Locals area<br><br></td>`
2276 :raw-html:`<td>Saved registers area<br><br></td>`
2278 :raw-html:`<tr style="border-style: none hidden none hidden;">`
2279 :raw-html:`<td><br></td>`
2282 :raw-html:`<td>Previous Frame<br><br></td>`
2284 :raw-html:`</table>`
2286 The *linkage* area is used by a callee to save special registers prior to
2287 allocating its own frame. Only three entries are relevant to LLVM. The first
2288 entry is the previous stack pointer (sp), aka link. This allows probing tools
2289 like gdb or exception handlers to quickly scan the frames in the stack. A
2290 function epilog can also use the link to pop the frame from the stack. The
2291 third entry in the linkage area is used to save the return address from the lr
2292 register. Finally, as mentioned above, the last entry is used to save the
2293 previous frame pointer (r31.) The entries in the linkage area are the size of a
2294 GPR, thus the linkage area is 24 bytes long in 32 bit mode and 48 bytes in 64
2297 32 bit linkage area:
2299 :raw-html:`<table border="1" cellspacing="0">`
2301 :raw-html:`<td>0</td>`
2302 :raw-html:`<td>Saved SP (r1)</td>`
2305 :raw-html:`<td>4</td>`
2306 :raw-html:`<td>Saved CR</td>`
2309 :raw-html:`<td>8</td>`
2310 :raw-html:`<td>Saved LR</td>`
2313 :raw-html:`<td>12</td>`
2314 :raw-html:`<td>Reserved</td>`
2317 :raw-html:`<td>16</td>`
2318 :raw-html:`<td>Reserved</td>`
2321 :raw-html:`<td>20</td>`
2322 :raw-html:`<td>Saved FP (r31)</td>`
2324 :raw-html:`</table>`
2326 64 bit linkage area:
2328 :raw-html:`<table border="1" cellspacing="0">`
2330 :raw-html:`<td>0</td>`
2331 :raw-html:`<td>Saved SP (r1)</td>`
2334 :raw-html:`<td>8</td>`
2335 :raw-html:`<td>Saved CR</td>`
2338 :raw-html:`<td>16</td>`
2339 :raw-html:`<td>Saved LR</td>`
2342 :raw-html:`<td>24</td>`
2343 :raw-html:`<td>Reserved</td>`
2346 :raw-html:`<td>32</td>`
2347 :raw-html:`<td>Reserved</td>`
2350 :raw-html:`<td>40</td>`
2351 :raw-html:`<td>Saved FP (r31)</td>`
2353 :raw-html:`</table>`
2355 The *parameter area* is used to store arguments being passed to a callee
2356 function. Following the PowerPC ABI, the first few arguments are actually
2357 passed in registers, with the space in the parameter area unused. However, if
2358 there are not enough registers or the callee is a thunk or vararg function,
2359 these register arguments can be spilled into the parameter area. Thus, the
2360 parameter area must be large enough to store all the parameters for the largest
2361 call sequence made by the caller. The size must also be minimally large enough
2362 to spill registers r3-r10. This allows callees blind to the call signature,
2363 such as thunks and vararg functions, enough space to cache the argument
2364 registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64
2365 bit mode.) Also note that since the parameter area is a fixed offset from the
2366 top of the frame, that a callee can access its spilt arguments using fixed
2367 offsets from the stack pointer (or base pointer.)
2369 Combining the information about the linkage, parameter areas and alignment. A
2370 stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit mode.
2372 The *dynamic area* starts out as size zero. If a function uses dynamic alloca
2373 then space is added to the stack, the linkage and parameter areas are shifted to
2374 top of stack, and the new space is available immediately below the linkage and
2375 parameter areas. The cost of shifting the linkage and parameter areas is minor
2376 since only the link value needs to be copied. The link value can be easily
2377 fetched by adding the original frame size to the base pointer. Note that
2378 allocations in the dynamic space need to observe 16 byte alignment.
2380 The *locals area* is where the llvm compiler reserves space for local variables.
2382 The *saved registers area* is where the llvm compiler spills callee saved
2383 registers on entry to the callee.
2388 The llvm prolog and epilog are the same as described in the PowerPC ABI, with
2389 the following exceptions. Callee saved registers are spilled after the frame is
2390 created. This allows the llvm epilog/prolog support to be common with other
2391 targets. The base pointer callee saved register r31 is saved in the TOC slot of
2392 linkage area. This simplifies allocation of space for the base pointer and
2393 makes it convenient to locate programatically and during debugging.
2400 TODO - More to come.
2405 The NVPTX code generator under lib/Target/NVPTX is an open-source version of
2406 the NVIDIA NVPTX code generator for LLVM. It is contributed by NVIDIA and is
2407 a port of the code generator used in the CUDA compiler (nvcc). It targets the
2408 PTX 3.0/3.1 ISA and can target any compute capability greater than or equal to
2411 This target is of production quality and should be completely compatible with
2412 the official NVIDIA toolchain.
2414 Code Generator Options:
2416 :raw-html:`<table border="1" cellspacing="0">`
2418 :raw-html:`<th>Option</th>`
2419 :raw-html:`<th>Description</th>`
2422 :raw-html:`<td>sm_20</td>`
2423 :raw-html:`<td align="left">Set shader model/compute capability to 2.0</td>`
2426 :raw-html:`<td>sm_21</td>`
2427 :raw-html:`<td align="left">Set shader model/compute capability to 2.1</td>`
2430 :raw-html:`<td>sm_30</td>`
2431 :raw-html:`<td align="left">Set shader model/compute capability to 3.0</td>`
2434 :raw-html:`<td>sm_35</td>`
2435 :raw-html:`<td align="left">Set shader model/compute capability to 3.5</td>`
2438 :raw-html:`<td>ptx30</td>`
2439 :raw-html:`<td align="left">Target PTX 3.0</td>`
2442 :raw-html:`<td>ptx31</td>`
2443 :raw-html:`<td align="left">Target PTX 3.1</td>`
2445 :raw-html:`</table>`