3 ==========================================
4 The LLVM Target-Independent Code Generator
5 ==========================================
7 .. role:: raw-html(raw)
13 .unknown { background-color: #C0C0C0; text-align: center; }
14 .unknown:before { content: "?" }
15 .no { background-color: #C11B17 }
16 .no:before { content: "N" }
17 .partial { background-color: #F88017 }
18 .yes { background-color: #0F0; }
19 .yes:before { content: "Y" }
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 `LLVM code representation <LangRef.html>`_. 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 <TableGenFundamentals>` 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 `TableGen <TableGenFundamentals.html>`_ 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. It is essentially an array of ``TargetInstrDescriptor``
289 objects, each of which describes one instruction the target
290 supports. Descriptors define things like the mnemonic for the opcode, the number
291 of operands, the list of implicit register uses and defs, whether the
292 instruction has certain target-independent properties (accesses memory, is
293 commutable, etc), and holds any target-specific flags.
295 The ``TargetFrameInfo`` class
296 -----------------------------
298 The ``TargetFrameInfo`` class is used to provide information about the stack
299 frame layout of the target. It holds the direction of stack growth, the known
300 stack alignment on entry to each function, and the offset to the local area.
301 The offset to the local area is the offset from the stack pointer on function
302 entry to the first location where function data (local variables, spill
303 locations) can be stored.
305 The ``TargetSubtarget`` class
306 -----------------------------
308 The ``TargetSubtarget`` class is used to provide information about the specific
309 chip set being targeted. A sub-target informs code generation of which
310 instructions are supported, instruction latencies and instruction execution
311 itinerary; i.e., which processing units are used, in what order, and for how
314 The ``TargetJITInfo`` class
315 ---------------------------
317 The ``TargetJITInfo`` class exposes an abstract interface used by the
318 Just-In-Time code generator to perform target-specific activities, such as
319 emitting stubs. If a ``TargetMachine`` supports JIT code generation, it should
320 provide one of these objects through the ``getJITInfo`` method.
322 .. _code being generated:
323 .. _machine code representation:
325 Machine code description classes
326 ================================
328 At the high-level, LLVM code is translated to a machine specific representation
329 formed out of :raw-html:`<tt>` `MachineFunction`_ :raw-html:`</tt>`,
330 :raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>`, and :raw-html:`<tt>`
331 `MachineInstr`_ :raw-html:`</tt>` instances (defined in
332 ``include/llvm/CodeGen``). This representation is completely target agnostic,
333 representing instructions in their most abstract form: an opcode and a series of
334 operands. This representation is designed to support both an SSA representation
335 for machine code, as well as a register allocated, non-SSA form.
339 The ``MachineInstr`` class
340 --------------------------
342 Target machine instructions are represented as instances of the ``MachineInstr``
343 class. This class is an extremely abstract way of representing machine
344 instructions. In particular, it only keeps track of an opcode number and a set
347 The opcode number is a simple unsigned integer that only has meaning to a
348 specific backend. All of the instructions for a target should be defined in the
349 ``*InstrInfo.td`` file for the target. The opcode enum values are auto-generated
350 from this description. The ``MachineInstr`` class does not have any information
351 about how to interpret the instruction (i.e., what the semantics of the
352 instruction are); for that you must refer to the :raw-html:`<tt>`
353 `TargetInstrInfo`_ :raw-html:`</tt>` class.
355 The operands of a machine instruction can be of several different types: a
356 register reference, a constant integer, a basic block reference, etc. In
357 addition, a machine operand should be marked as a def or a use of the value
358 (though only registers are allowed to be defs).
360 By convention, the LLVM code generator orders instruction operands so that all
361 register definitions come before the register uses, even on architectures that
362 are normally printed in other orders. For example, the SPARC add instruction:
363 "``add %i1, %i2, %i3``" adds the "%i1", and "%i2" registers and stores the
364 result into the "%i3" register. In the LLVM code generator, the operands should
365 be stored as "``%i3, %i1, %i2``": with the destination first.
367 Keeping destination (definition) operands at the beginning of the operand list
368 has several advantages. In particular, the debugging printer will print the
369 instruction like this:
375 Also if the first operand is a def, it is easier to `create instructions`_ whose
376 only def is the first operand.
378 .. _create instructions:
380 Using the ``MachineInstrBuilder.h`` functions
381 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
383 Machine instructions are created by using the ``BuildMI`` functions, located in
384 the ``include/llvm/CodeGen/MachineInstrBuilder.h`` file. The ``BuildMI``
385 functions make it easy to build arbitrary machine instructions. Usage of the
386 ``BuildMI`` functions look like this:
390 // Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
391 // instruction. The '1' specifies how many operands will be added.
392 MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
394 // Create the same instr, but insert it at the end of a basic block.
395 MachineBasicBlock &MBB = ...
396 BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
398 // Create the same instr, but insert it before a specified iterator point.
399 MachineBasicBlock::iterator MBBI = ...
400 BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
402 // Create a 'cmp Reg, 0' instruction, no destination reg.
403 MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
405 // Create an 'sahf' instruction which takes no operands and stores nothing.
406 MI = BuildMI(X86::SAHF, 0);
408 // Create a self looping branch instruction.
409 BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
411 The key thing to remember with the ``BuildMI`` functions is that you have to
412 specify the number of operands that the machine instruction will take. This
413 allows for efficient memory allocation. You also need to specify if operands
414 default to be uses of values, not definitions. If you need to add a definition
415 operand (other than the optional destination register), you must explicitly mark
420 MI.addReg(Reg, RegState::Define);
422 Fixed (preassigned) registers
423 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
425 One important issue that the code generator needs to be aware of is the presence
426 of fixed registers. In particular, there are often places in the instruction
427 stream where the register allocator *must* arrange for a particular value to be
428 in a particular register. This can occur due to limitations of the instruction
429 set (e.g., the X86 can only do a 32-bit divide with the ``EAX``/``EDX``
430 registers), or external factors like calling conventions. In any case, the
431 instruction selector should emit code that copies a virtual register into or out
432 of a physical register when needed.
434 For example, consider this simple LLVM example:
438 define i32 @test(i32 %X, i32 %Y) {
443 The X86 instruction selector produces this machine code for the ``div`` and
444 ``ret`` (use "``llc X.bc -march=x86 -print-machineinstrs``" to get this):
449 %EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX
450 %reg1027 = sar %reg1024, 31
451 %EDX = mov %reg1027 ;; Sign extend X into EDX
452 idiv %reg1025 ;; Divide by Y (in reg1025)
453 %reg1026 = mov %EAX ;; Read the result (Z) out of EAX
456 %EAX = mov %reg1026 ;; 32-bit return value goes in EAX
459 By the end of code generation, the register allocator has coalesced the
460 registers and deleted the resultant identity moves producing the following
465 ;; X is in EAX, Y is in ECX
471 This approach is extremely general (if it can handle the X86 architecture, it
472 can handle anything!) and allows all of the target specific knowledge about the
473 instruction stream to be isolated in the instruction selector. Note that
474 physical registers should have a short lifetime for good code generation, and
475 all physical registers are assumed dead on entry to and exit from basic blocks
476 (before register allocation). Thus, if you need a value to be live across basic
477 block boundaries, it *must* live in a virtual register.
479 Call-clobbered registers
480 ^^^^^^^^^^^^^^^^^^^^^^^^
482 Some machine instructions, like calls, clobber a large number of physical
483 registers. Rather than adding ``<def,dead>`` operands for all of them, it is
484 possible to use an ``MO_RegisterMask`` operand instead. The register mask
485 operand holds a bit mask of preserved registers, and everything else is
486 considered to be clobbered by the instruction.
488 Machine code in SSA form
489 ^^^^^^^^^^^^^^^^^^^^^^^^
491 ``MachineInstr``'s are initially selected in SSA-form, and are maintained in
492 SSA-form until register allocation happens. For the most part, this is
493 trivially simple since LLVM is already in SSA form; LLVM PHI nodes become
494 machine code PHI nodes, and virtual registers are only allowed to have a single
497 After register allocation, machine code is no longer in SSA-form because there
498 are no virtual registers left in the code.
500 .. _MachineBasicBlock:
502 The ``MachineBasicBlock`` class
503 -------------------------------
505 The ``MachineBasicBlock`` class contains a list of machine instructions
506 (:raw-html:`<tt>` `MachineInstr`_ :raw-html:`</tt>` instances). It roughly
507 corresponds to the LLVM code input to the instruction selector, but there can be
508 a one-to-many mapping (i.e. one LLVM basic block can map to multiple machine
509 basic blocks). The ``MachineBasicBlock`` class has a "``getBasicBlock``" method,
510 which returns the LLVM basic block that it comes from.
514 The ``MachineFunction`` class
515 -----------------------------
517 The ``MachineFunction`` class contains a list of machine basic blocks
518 (:raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>` instances). It
519 corresponds one-to-one with the LLVM function input to the instruction selector.
520 In addition to a list of basic blocks, the ``MachineFunction`` contains a a
521 ``MachineConstantPool``, a ``MachineFrameInfo``, a ``MachineFunctionInfo``, and
522 a ``MachineRegisterInfo``. See ``include/llvm/CodeGen/MachineFunction.h`` for
525 ``MachineInstr Bundles``
526 ------------------------
528 LLVM code generator can model sequences of instructions as MachineInstr
529 bundles. A MI bundle can model a VLIW group / pack which contains an arbitrary
530 number of parallel instructions. It can also be used to model a sequential list
531 of instructions (potentially with data dependencies) that cannot be legally
532 separated (e.g. ARM Thumb2 IT blocks).
534 Conceptually a MI bundle is a MI with a number of other MIs nested within:
572 MI bundle support does not change the physical representations of
573 MachineBasicBlock and MachineInstr. All the MIs (including top level and nested
574 ones) are stored as sequential list of MIs. The "bundled" MIs are marked with
575 the 'InsideBundle' flag. A top level MI with the special BUNDLE opcode is used
576 to represent the start of a bundle. It's legal to mix BUNDLE MIs with indiviual
577 MIs that are not inside bundles nor represent bundles.
579 MachineInstr passes should operate on a MI bundle as a single unit. Member
580 methods have been taught to correctly handle bundles and MIs inside bundles.
581 The MachineBasicBlock iterator has been modified to skip over bundled MIs to
582 enforce the bundle-as-a-single-unit concept. An alternative iterator
583 instr_iterator has been added to MachineBasicBlock to allow passes to iterate
584 over all of the MIs in a MachineBasicBlock, including those which are nested
585 inside bundles. The top level BUNDLE instruction must have the correct set of
586 register MachineOperand's that represent the cumulative inputs and outputs of
589 Packing / bundling of MachineInstr's should be done as part of the register
590 allocation super-pass. More specifically, the pass which determines what MIs
591 should be bundled together must be done after code generator exits SSA form
592 (i.e. after two-address pass, PHI elimination, and copy coalescing). Bundles
593 should only be finalized (i.e. adding BUNDLE MIs and input and output register
594 MachineOperands) after virtual registers have been rewritten into physical
595 registers. This requirement eliminates the need to add virtual register operands
596 to BUNDLE instructions which would effectively double the virtual register def
604 The MC Layer is used to represent and process code at the raw machine code
605 level, devoid of "high level" information like "constant pools", "jump tables",
606 "global variables" or anything like that. At this level, LLVM handles things
607 like label names, machine instructions, and sections in the object file. The
608 code in this layer is used for a number of important purposes: the tail end of
609 the code generator uses it to write a .s or .o file, and it is also used by the
610 llvm-mc tool to implement standalone machine code assemblers and disassemblers.
612 This section describes some of the important classes. There are also a number
613 of important subsystems that interact at this layer, they are described later in
618 The ``MCStreamer`` API
619 ----------------------
621 MCStreamer is best thought of as an assembler API. It is an abstract API which
622 is *implemented* in different ways (e.g. to output a .s file, output an ELF .o
623 file, etc) but whose API correspond directly to what you see in a .s file.
624 MCStreamer has one method per directive, such as EmitLabel, EmitSymbolAttribute,
625 SwitchSection, EmitValue (for .byte, .word), etc, which directly correspond to
626 assembly level directives. It also has an EmitInstruction method, which is used
627 to output an MCInst to the streamer.
629 This API is most important for two clients: the llvm-mc stand-alone assembler is
630 effectively a parser that parses a line, then invokes a method on MCStreamer. In
631 the code generator, the `Code Emission`_ phase of the code generator lowers
632 higher level LLVM IR and Machine* constructs down to the MC layer, emitting
633 directives through MCStreamer.
635 On the implementation side of MCStreamer, there are two major implementations:
636 one for writing out a .s file (MCAsmStreamer), and one for writing out a .o
637 file (MCObjectStreamer). MCAsmStreamer is a straight-forward implementation
638 that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but
639 MCObjectStreamer implements a full assembler.
641 The ``MCContext`` class
642 -----------------------
644 The MCContext class is the owner of a variety of uniqued data structures at the
645 MC layer, including symbols, sections, etc. As such, this is the class that you
646 interact with to create symbols and sections. This class can not be subclassed.
648 The ``MCSymbol`` class
649 ----------------------
651 The MCSymbol class represents a symbol (aka label) in the assembly file. There
652 are two interesting kinds of symbols: assembler temporary symbols, and normal
653 symbols. Assembler temporary symbols are used and processed by the assembler
654 but are discarded when the object file is produced. The distinction is usually
655 represented by adding a prefix to the label, for example "L" labels are
656 assembler temporary labels in MachO.
658 MCSymbols are created by MCContext and uniqued there. This means that MCSymbols
659 can be compared for pointer equivalence to find out if they are the same symbol.
660 Note that pointer inequality does not guarantee the labels will end up at
661 different addresses though. It's perfectly legal to output something like this
670 In this case, both the foo and bar symbols will have the same address.
672 The ``MCSection`` class
673 -----------------------
675 The ``MCSection`` class represents an object-file specific section. It is
676 subclassed by object file specific implementations (e.g. ``MCSectionMachO``,
677 ``MCSectionCOFF``, ``MCSectionELF``) and these are created and uniqued by
678 MCContext. The MCStreamer has a notion of the current section, which can be
679 changed with the SwitchToSection method (which corresponds to a ".section"
680 directive in a .s file).
687 The ``MCInst`` class is a target-independent representation of an instruction.
688 It is a simple class (much more so than `MachineInstr`_) that holds a
689 target-specific opcode and a vector of MCOperands. MCOperand, in turn, is a
690 simple discriminated union of three cases: 1) a simple immediate, 2) a target
691 register ID, 3) a symbolic expression (e.g. "``Lfoo-Lbar+42``") as an MCExpr.
693 MCInst is the common currency used to represent machine instructions at the MC
694 layer. It is the type used by the instruction encoder, the instruction printer,
695 and the type generated by the assembly parser and disassembler.
697 .. _Target-independent algorithms:
698 .. _code generation algorithm:
700 Target-independent code generation algorithms
701 =============================================
703 This section documents the phases described in the `high-level design of the
704 code generator`_. It explains how they work and some of the rationale behind
707 .. _Instruction Selection:
708 .. _instruction selection section:
710 Instruction Selection
711 ---------------------
713 Instruction Selection is the process of translating LLVM code presented to the
714 code generator into target-specific machine instructions. There are several
715 well-known ways to do this in the literature. LLVM uses a SelectionDAG based
716 instruction selector.
718 Portions of the DAG instruction selector are generated from the target
719 description (``*.td``) files. Our goal is for the entire instruction selector
720 to be generated from these ``.td`` files, though currently there are still
721 things that require custom C++ code.
725 Introduction to SelectionDAGs
726 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
728 The SelectionDAG provides an abstraction for code representation in a way that
729 is amenable to instruction selection using automatic techniques
730 (e.g. dynamic-programming based optimal pattern matching selectors). It is also
731 well-suited to other phases of code generation; in particular, instruction
732 scheduling (SelectionDAG's are very close to scheduling DAGs post-selection).
733 Additionally, the SelectionDAG provides a host representation where a large
734 variety of very-low-level (but target-independent) `optimizations`_ may be
735 performed; ones which require extensive information about the instructions
736 efficiently supported by the target.
738 The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
739 ``SDNode`` class. The primary payload of the ``SDNode`` is its operation code
740 (Opcode) that indicates what operation the node performs and the operands to the
741 operation. The various operation node types are described at the top of the
742 ``include/llvm/CodeGen/SelectionDAGNodes.h`` file.
744 Although most operations define a single value, each node in the graph may
745 define multiple values. For example, a combined div/rem operation will define
746 both the dividend and the remainder. Many other situations require multiple
747 values as well. Each node also has some number of operands, which are edges to
748 the node defining the used value. Because nodes may define multiple values,
749 edges are represented by instances of the ``SDValue`` class, which is a
750 ``<SDNode, unsigned>`` pair, indicating the node and result value being used,
751 respectively. Each value produced by an ``SDNode`` has an associated ``MVT``
752 (Machine Value Type) indicating what the type of the value is.
754 SelectionDAGs contain two different kinds of values: those that represent data
755 flow and those that represent control flow dependencies. Data values are simple
756 edges with an integer or floating point value type. Control edges are
757 represented as "chain" edges which are of type ``MVT::Other``. These edges
758 provide an ordering between nodes that have side effects (such as loads, stores,
759 calls, returns, etc). All nodes that have side effects should take a token
760 chain as input and produce a new one as output. By convention, token chain
761 inputs are always operand #0, and chain results are always the last value
762 produced by an operation.
764 A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
765 always a marker node with an Opcode of ``ISD::EntryToken``. The Root node is
766 the final side-effecting node in the token chain. For example, in a single basic
767 block function it would be the return node.
769 One important concept for SelectionDAGs is the notion of a "legal" vs.
770 "illegal" DAG. A legal DAG for a target is one that only uses supported
771 operations and supported types. On a 32-bit PowerPC, for example, a DAG with a
772 value of type i1, i8, i16, or i64 would be illegal, as would a DAG that uses a
773 SREM or UREM operation. The `legalize types`_ and `legalize operations`_ phases
774 are responsible for turning an illegal DAG into a legal DAG.
776 .. _SelectionDAG-Process:
778 SelectionDAG Instruction Selection Process
779 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
781 SelectionDAG-based instruction selection consists of the following steps:
783 #. `Build initial DAG`_ --- This stage performs a simple translation from the
784 input LLVM code to an illegal SelectionDAG.
786 #. `Optimize SelectionDAG`_ --- This stage performs simple optimizations on the
787 SelectionDAG to simplify it, and recognize meta instructions (like rotates
788 and ``div``/``rem`` pairs) for targets that support these meta operations.
789 This makes the resultant code more efficient and the `select instructions
790 from DAG`_ phase (below) simpler.
792 #. `Legalize SelectionDAG Types`_ --- This stage transforms SelectionDAG nodes
793 to eliminate any types that are unsupported on the target.
795 #. `Optimize SelectionDAG`_ --- The SelectionDAG optimizer is run to clean up
796 redundancies exposed by type legalization.
798 #. `Legalize SelectionDAG Ops`_ --- This stage transforms SelectionDAG nodes to
799 eliminate any operations that are unsupported on the target.
801 #. `Optimize SelectionDAG`_ --- The SelectionDAG optimizer is run to eliminate
802 inefficiencies introduced by operation legalization.
804 #. `Select instructions from DAG`_ --- Finally, the target instruction selector
805 matches the DAG operations to target instructions. This process translates
806 the target-independent input DAG into another DAG of target instructions.
808 #. `SelectionDAG Scheduling and Formation`_ --- The last phase assigns a linear
809 order to the instructions in the target-instruction DAG and emits them into
810 the MachineFunction being compiled. This step uses traditional prepass
811 scheduling techniques.
813 After all of these steps are complete, the SelectionDAG is destroyed and the
814 rest of the code generation passes are run.
816 One great way to visualize what is going on here is to take advantage of a few
817 LLC command line options. The following options pop up a window displaying the
818 SelectionDAG at specific times (if you only get errors printed to the console
819 while using this, you probably `need to configure your
820 system <ProgrammersManual.html#ViewGraph>`_ to add support for it).
822 * ``-view-dag-combine1-dags`` displays the DAG after being built, before the
823 first optimization pass.
825 * ``-view-legalize-dags`` displays the DAG before Legalization.
827 * ``-view-dag-combine2-dags`` displays the DAG before the second optimization
830 * ``-view-isel-dags`` displays the DAG before the Select phase.
832 * ``-view-sched-dags`` displays the DAG before Scheduling.
834 The ``-view-sunit-dags`` displays the Scheduler's dependency graph. This graph
835 is based on the final SelectionDAG, with nodes that must be scheduled together
836 bundled into a single scheduling-unit node, and with immediate operands and
837 other nodes that aren't relevant for scheduling omitted.
839 .. _Build initial DAG:
841 Initial SelectionDAG Construction
842 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
844 The initial SelectionDAG is na\ :raw-html:`ï`\ vely peephole expanded from
845 the LLVM input by the ``SelectionDAGBuilder`` class. The intent of this pass
846 is to expose as much low-level, target-specific details to the SelectionDAG as
847 possible. This pass is mostly hard-coded (e.g. an LLVM ``add`` turns into an
848 ``SDNode add`` while a ``getelementptr`` is expanded into the obvious
849 arithmetic). This pass requires target-specific hooks to lower calls, returns,
850 varargs, etc. For these features, the :raw-html:`<tt>` `TargetLowering`_
851 :raw-html:`</tt>` interface is used.
854 .. _Legalize SelectionDAG Types:
855 .. _Legalize SelectionDAG Ops:
857 SelectionDAG LegalizeTypes Phase
858 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
860 The Legalize phase is in charge of converting a DAG to only use the types that
861 are natively supported by the target.
863 There are two main ways of converting values of unsupported scalar types to
864 values of supported types: converting small types to larger types ("promoting"),
865 and breaking up large integer types into smaller ones ("expanding"). For
866 example, a target might require that all f32 values are promoted to f64 and that
867 all i1/i8/i16 values are promoted to i32. The same target might require that
868 all i64 values be expanded into pairs of i32 values. These changes can insert
869 sign and zero extensions as needed to make sure that the final code has the same
870 behavior as the input.
872 There are two main ways of converting values of unsupported vector types to
873 value of supported types: splitting vector types, multiple times if necessary,
874 until a legal type is found, and extending vector types by adding elements to
875 the end to round them out to legal types ("widening"). If a vector gets split
876 all the way down to single-element parts with no supported vector type being
877 found, the elements are converted to scalars ("scalarizing").
879 A target implementation tells the legalizer which types are supported (and which
880 register class to use for them) by calling the ``addRegisterClass`` method in
881 its ``TargetLowering`` constructor.
883 .. _legalize operations:
886 SelectionDAG Legalize Phase
887 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
889 The Legalize phase is in charge of converting a DAG to only use the operations
890 that are natively supported by the target.
892 Targets often have weird constraints, such as not supporting every operation on
893 every supported datatype (e.g. X86 does not support byte conditional moves and
894 PowerPC does not support sign-extending loads from a 16-bit memory location).
895 Legalize takes care of this by open-coding another sequence of operations to
896 emulate the operation ("expansion"), by promoting one type to a larger type that
897 supports the operation ("promotion"), or by using a target-specific hook to
898 implement the legalization ("custom").
900 A target implementation tells the legalizer which operations are not supported
901 (and which of the above three actions to take) by calling the
902 ``setOperationAction`` method in its ``TargetLowering`` constructor.
904 Prior to the existence of the Legalize passes, we required that every target
905 `selector`_ supported and handled every operator and type even if they are not
906 natively supported. The introduction of the Legalize phases allows all of the
907 canonicalization patterns to be shared across targets, and makes it very easy to
908 optimize the canonicalized code because it is still in the form of a DAG.
911 .. _Optimize SelectionDAG:
914 SelectionDAG Optimization Phase: the DAG Combiner
915 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
917 The SelectionDAG optimization phase is run multiple times for code generation,
918 immediately after the DAG is built and once after each legalization. The first
919 run of the pass allows the initial code to be cleaned up (e.g. performing
920 optimizations that depend on knowing that the operators have restricted type
921 inputs). Subsequent runs of the pass clean up the messy code generated by the
922 Legalize passes, which allows Legalize to be very simple (it can focus on making
923 code legal instead of focusing on generating *good* and legal code).
925 One important class of optimizations performed is optimizing inserted sign and
926 zero extension instructions. We currently use ad-hoc techniques, but could move
927 to more rigorous techniques in the future. Here are some good papers on the
930 "`Widening integer arithmetic <http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html>`_" :raw-html:`<br>`
931 Kevin Redwine and Norman Ramsey :raw-html:`<br>`
932 International Conference on Compiler Construction (CC) 2004
934 "`Effective sign extension elimination <http://portal.acm.org/citation.cfm?doid=512529.512552>`_" :raw-html:`<br>`
935 Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani :raw-html:`<br>`
936 Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
939 .. _Select instructions from DAG:
941 SelectionDAG Select Phase
942 ^^^^^^^^^^^^^^^^^^^^^^^^^
944 The Select phase is the bulk of the target-specific code for instruction
945 selection. This phase takes a legal SelectionDAG as input, pattern matches the
946 instructions supported by the target to this DAG, and produces a new DAG of
947 target code. For example, consider the following LLVM fragment:
951 %t1 = fadd float %W, %X
952 %t2 = fmul float %t1, %Y
953 %t3 = fadd float %t2, %Z
955 This LLVM code corresponds to a SelectionDAG that looks basically like this:
959 (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
961 If a target supports floating point multiply-and-add (FMA) operations, one of
962 the adds can be merged with the multiply. On the PowerPC, for example, the
963 output of the instruction selector might look like this DAG:
967 (FMADDS (FADDS W, X), Y, Z)
969 The ``FMADDS`` instruction is a ternary instruction that multiplies its first
970 two operands and adds the third (as single-precision floating-point numbers).
971 The ``FADDS`` instruction is a simple binary single-precision add instruction.
972 To perform this pattern match, the PowerPC backend includes the following
973 instruction definitions:
976 :emphasize-lines: 4-5,9
978 def FMADDS : AForm_1<59, 29,
979 (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
980 "fmadds $FRT, $FRA, $FRC, $FRB",
981 [(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
983 def FADDS : AForm_2<59, 21,
984 (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
985 "fadds $FRT, $FRA, $FRB",
986 [(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))]>;
988 The highlighted portion of the instruction definitions indicates the pattern
989 used to match the instructions. The DAG operators (like ``fmul``/``fadd``)
990 are defined in the ``include/llvm/Target/TargetSelectionDAG.td`` file.
991 "``F4RC``" is the register class of the input and result values.
993 The TableGen DAG instruction selector generator reads the instruction patterns
994 in the ``.td`` file and automatically builds parts of the pattern matching code
995 for your target. It has the following strengths:
997 * At compiler-compiler time, it analyzes your instruction patterns and tells you
998 if your patterns make sense or not.
1000 * It can handle arbitrary constraints on operands for the pattern match. In
1001 particular, it is straight-forward to say things like "match any immediate
1002 that is a 13-bit sign-extended value". For examples, see the ``immSExt16``
1003 and related ``tblgen`` classes in the PowerPC backend.
1005 * It knows several important identities for the patterns defined. For example,
1006 it knows that addition is commutative, so it allows the ``FMADDS`` pattern
1007 above to match "``(fadd X, (fmul Y, Z))``" as well as "``(fadd (fmul X, Y),
1008 Z)``", without the target author having to specially handle this case.
1010 * It has a full-featured type-inferencing system. In particular, you should
1011 rarely have to explicitly tell the system what type parts of your patterns
1012 are. In the ``FMADDS`` case above, we didn't have to tell ``tblgen`` that all
1013 of the nodes in the pattern are of type 'f32'. It was able to infer and
1014 propagate this knowledge from the fact that ``F4RC`` has type 'f32'.
1016 * Targets can define their own (and rely on built-in) "pattern fragments".
1017 Pattern fragments are chunks of reusable patterns that get inlined into your
1018 patterns during compiler-compiler time. For example, the integer "``(not
1019 x)``" operation is actually defined as a pattern fragment that expands as
1020 "``(xor x, -1)``", since the SelectionDAG does not have a native '``not``'
1021 operation. Targets can define their own short-hand fragments as they see fit.
1022 See the definition of '``not``' and '``ineg``' for examples.
1024 * In addition to instructions, targets can specify arbitrary patterns that map
1025 to one or more instructions using the 'Pat' class. For example, the PowerPC
1026 has no way to load an arbitrary integer immediate into a register in one
1027 instruction. To tell tblgen how to do this, it defines:
1031 // Arbitrary immediate support. Implement in terms of LIS/ORI.
1032 def : Pat<(i32 imm:$imm),
1033 (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;
1035 If none of the single-instruction patterns for loading an immediate into a
1036 register match, this will be used. This rule says "match an arbitrary i32
1037 immediate, turning it into an ``ORI`` ('or a 16-bit immediate') and an ``LIS``
1038 ('load 16-bit immediate, where the immediate is shifted to the left 16 bits')
1039 instruction". To make this work, the ``LO16``/``HI16`` node transformations
1040 are used to manipulate the input immediate (in this case, take the high or low
1041 16-bits of the immediate).
1043 * While the system does automate a lot, it still allows you to write custom C++
1044 code to match special cases if there is something that is hard to
1047 While it has many strengths, the system currently has some limitations,
1048 primarily because it is a work in progress and is not yet finished:
1050 * Overall, there is no way to define or match SelectionDAG nodes that define
1051 multiple values (e.g. ``SMUL_LOHI``, ``LOAD``, ``CALL``, etc). This is the
1052 biggest reason that you currently still *have to* write custom C++ code
1053 for your instruction selector.
1055 * There is no great way to support matching complex addressing modes yet. In
1056 the future, we will extend pattern fragments to allow them to define multiple
1057 values (e.g. the four operands of the `X86 addressing mode`_, which are
1058 currently matched with custom C++ code). In addition, we'll extend fragments
1059 so that a fragment can match multiple different patterns.
1061 * We don't automatically infer flags like ``isStore``/``isLoad`` yet.
1063 * We don't automatically generate the set of supported registers and operations
1064 for the `Legalizer`_ yet.
1066 * We don't have a way of tying in custom legalized nodes yet.
1068 Despite these limitations, the instruction selector generator is still quite
1069 useful for most of the binary and logical operations in typical instruction
1070 sets. If you run into any problems or can't figure out how to do something,
1071 please let Chris know!
1073 .. _Scheduling and Formation:
1074 .. _SelectionDAG Scheduling and Formation:
1076 SelectionDAG Scheduling and Formation Phase
1077 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1079 The scheduling phase takes the DAG of target instructions from the selection
1080 phase and assigns an order. The scheduler can pick an order depending on
1081 various constraints of the machines (i.e. order for minimal register pressure or
1082 try to cover instruction latencies). Once an order is established, the DAG is
1083 converted to a list of :raw-html:`<tt>` `MachineInstr`_\s :raw-html:`</tt>` and
1084 the SelectionDAG is destroyed.
1086 Note that this phase is logically separate from the instruction selection phase,
1087 but is tied to it closely in the code because it operates on SelectionDAGs.
1089 Future directions for the SelectionDAG
1090 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1092 #. Optional function-at-a-time selection.
1094 #. Auto-generate entire selector from ``.td`` file.
1096 .. _SSA-based Machine Code Optimizations:
1098 SSA-based Machine Code Optimizations
1099 ------------------------------------
1106 Live Intervals are the ranges (intervals) where a variable is *live*. They are
1107 used by some `register allocator`_ passes to determine if two or more virtual
1108 registers which require the same physical register are live at the same point in
1109 the program (i.e., they conflict). When this situation occurs, one virtual
1110 register must be *spilled*.
1112 Live Variable Analysis
1113 ^^^^^^^^^^^^^^^^^^^^^^
1115 The first step in determining the live intervals of variables is to calculate
1116 the set of registers that are immediately dead after the instruction (i.e., the
1117 instruction calculates the value, but it is never used) and the set of registers
1118 that are used by the instruction, but are never used after the instruction
1119 (i.e., they are killed). Live variable information is computed for
1120 each *virtual* register and *register allocatable* physical register
1121 in the function. This is done in a very efficient manner because it uses SSA to
1122 sparsely compute lifetime information for virtual registers (which are in SSA
1123 form) and only has to track physical registers within a block. Before register
1124 allocation, LLVM can assume that physical registers are only live within a
1125 single basic block. This allows it to do a single, local analysis to resolve
1126 physical register lifetimes within each basic block. If a physical register is
1127 not register allocatable (e.g., a stack pointer or condition codes), it is not
1130 Physical registers may be live in to or out of a function. Live in values are
1131 typically arguments in registers. Live out values are typically return values in
1132 registers. Live in values are marked as such, and are given a dummy "defining"
1133 instruction during live intervals analysis. If the last basic block of a
1134 function is a ``return``, then it's marked as using all live out values in the
1137 ``PHI`` nodes need to be handled specially, because the calculation of the live
1138 variable information from a depth first traversal of the CFG of the function
1139 won't guarantee that a virtual register used by the ``PHI`` node is defined
1140 before it's used. When a ``PHI`` node is encountered, only the definition is
1141 handled, because the uses will be handled in other basic blocks.
1143 For each ``PHI`` node of the current basic block, we simulate an assignment at
1144 the end of the current basic block and traverse the successor basic blocks. If a
1145 successor basic block has a ``PHI`` node and one of the ``PHI`` node's operands
1146 is coming from the current basic block, then the variable is marked as *alive*
1147 within the current basic block and all of its predecessor basic blocks, until
1148 the basic block with the defining instruction is encountered.
1150 Live Intervals Analysis
1151 ^^^^^^^^^^^^^^^^^^^^^^^
1153 We now have the information available to perform the live intervals analysis and
1154 build the live intervals themselves. We start off by numbering the basic blocks
1155 and machine instructions. We then handle the "live-in" values. These are in
1156 physical registers, so the physical register is assumed to be killed by the end
1157 of the basic block. Live intervals for virtual registers are computed for some
1158 ordering of the machine instructions ``[1, N]``. A live interval is an interval
1159 ``[i, j)``, where ``1 >= i >= j > N``, for which a variable is live.
1164 .. _Register Allocation:
1165 .. _register allocator:
1170 The *Register Allocation problem* consists in mapping a program
1171 :raw-html:`<b><tt>` P\ :sub:`v`\ :raw-html:`</tt></b>`, that can use an unbounded
1172 number of virtual registers, to a program :raw-html:`<b><tt>` P\ :sub:`p`\
1173 :raw-html:`</tt></b>` that contains a finite (possibly small) number of physical
1174 registers. Each target architecture has a different number of physical
1175 registers. If the number of physical registers is not enough to accommodate all
1176 the virtual registers, some of them will have to be mapped into memory. These
1177 virtuals are called *spilled virtuals*.
1179 How registers are represented in LLVM
1180 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1182 In LLVM, physical registers are denoted by integer numbers that normally range
1183 from 1 to 1023. To see how this numbering is defined for a particular
1184 architecture, you can read the ``GenRegisterNames.inc`` file for that
1185 architecture. For instance, by inspecting
1186 ``lib/Target/X86/X86GenRegisterInfo.inc`` we see that the 32-bit register
1187 ``EAX`` is denoted by 43, and the MMX register ``MM0`` is mapped to 65.
1189 Some architectures contain registers that share the same physical location. A
1190 notable example is the X86 platform. For instance, in the X86 architecture, the
1191 registers ``EAX``, ``AX`` and ``AL`` share the first eight bits. These physical
1192 registers are marked as *aliased* in LLVM. Given a particular architecture, you
1193 can check which registers are aliased by inspecting its ``RegisterInfo.td``
1194 file. Moreover, the class ``MCRegAliasIterator`` enumerates all the physical
1195 registers aliased to a register.
1197 Physical registers, in LLVM, are grouped in *Register Classes*. Elements in the
1198 same register class are functionally equivalent, and can be interchangeably
1199 used. Each virtual register can only be mapped to physical registers of a
1200 particular class. For instance, in the X86 architecture, some virtuals can only
1201 be allocated to 8 bit registers. A register class is described by
1202 ``TargetRegisterClass`` objects. To discover if a virtual register is
1203 compatible with a given physical, this code can be used:</p>
1207 bool RegMapping_Fer::compatible_class(MachineFunction &mf,
1210 assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
1211 "Target register must be physical");
1212 const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
1213 return trc->contains(p_reg);
1216 Sometimes, mostly for debugging purposes, it is useful to change the number of
1217 physical registers available in the target architecture. This must be done
1218 statically, inside the ``TargetRegsterInfo.td`` file. Just ``grep`` for
1219 ``RegisterClass``, the last parameter of which is a list of registers. Just
1220 commenting some out is one simple way to avoid them being used. A more polite
1221 way is to explicitly exclude some registers from the *allocation order*. See the
1222 definition of the ``GR8`` register class in
1223 ``lib/Target/X86/X86RegisterInfo.td`` for an example of this.
1225 Virtual registers are also denoted by integer numbers. Contrary to physical
1226 registers, different virtual registers never share the same number. Whereas
1227 physical registers are statically defined in a ``TargetRegisterInfo.td`` file
1228 and cannot be created by the application developer, that is not the case with
1229 virtual registers. In order to create new virtual registers, use the method
1230 ``MachineRegisterInfo::createVirtualRegister()``. This method will return a new
1231 virtual register. Use an ``IndexedMap<Foo, VirtReg2IndexFunctor>`` to hold
1232 information per virtual register. If you need to enumerate all virtual
1233 registers, use the function ``TargetRegisterInfo::index2VirtReg()`` to find the
1234 virtual register numbers:
1238 for (unsigned i = 0, e = MRI->getNumVirtRegs(); i != e; ++i) {
1239 unsigned VirtReg = TargetRegisterInfo::index2VirtReg(i);
1243 Before register allocation, the operands of an instruction are mostly virtual
1244 registers, although physical registers may also be used. In order to check if a
1245 given machine operand is a register, use the boolean function
1246 ``MachineOperand::isRegister()``. To obtain the integer code of a register, use
1247 ``MachineOperand::getReg()``. An instruction may define or use a register. For
1248 instance, ``ADD reg:1026 := reg:1025 reg:1024`` defines the registers 1024, and
1249 uses registers 1025 and 1026. Given a register operand, the method
1250 ``MachineOperand::isUse()`` informs if that register is being used by the
1251 instruction. The method ``MachineOperand::isDef()`` informs if that registers is
1254 We will call physical registers present in the LLVM bitcode before register
1255 allocation *pre-colored registers*. Pre-colored registers are used in many
1256 different situations, for instance, to pass parameters of functions calls, and
1257 to store results of particular instructions. There are two types of pre-colored
1258 registers: the ones *implicitly* defined, and those *explicitly*
1259 defined. Explicitly defined registers are normal operands, and can be accessed
1260 with ``MachineInstr::getOperand(int)::getReg()``. In order to check which
1261 registers are implicitly defined by an instruction, use the
1262 ``TargetInstrInfo::get(opcode)::ImplicitDefs``, where ``opcode`` is the opcode
1263 of the target instruction. One important difference between explicit and
1264 implicit physical registers is that the latter are defined statically for each
1265 instruction, whereas the former may vary depending on the program being
1266 compiled. For example, an instruction that represents a function call will
1267 always implicitly define or use the same set of physical registers. To read the
1268 registers implicitly used by an instruction, use
1269 ``TargetInstrInfo::get(opcode)::ImplicitUses``. Pre-colored registers impose
1270 constraints on any register allocation algorithm. The register allocator must
1271 make sure that none of them are overwritten by the values of virtual registers
1274 Mapping virtual registers to physical registers
1275 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1277 There are two ways to map virtual registers to physical registers (or to memory
1278 slots). The first way, that we will call *direct mapping*, is based on the use
1279 of methods of the classes ``TargetRegisterInfo``, and ``MachineOperand``. The
1280 second way, that we will call *indirect mapping*, relies on the ``VirtRegMap``
1281 class in order to insert loads and stores sending and getting values to and from
1284 The direct mapping provides more flexibility to the developer of the register
1285 allocator; however, it is more error prone, and demands more implementation
1286 work. Basically, the programmer will have to specify where load and store
1287 instructions should be inserted in the target function being compiled in order
1288 to get and store values in memory. To assign a physical register to a virtual
1289 register present in a given operand, use ``MachineOperand::setReg(p_reg)``. To
1290 insert a store instruction, use ``TargetInstrInfo::storeRegToStackSlot(...)``,
1291 and to insert a load instruction, use ``TargetInstrInfo::loadRegFromStackSlot``.
1293 The indirect mapping shields the application developer from the complexities of
1294 inserting load and store instructions. In order to map a virtual register to a
1295 physical one, use ``VirtRegMap::assignVirt2Phys(vreg, preg)``. In order to map
1296 a certain virtual register to memory, use
1297 ``VirtRegMap::assignVirt2StackSlot(vreg)``. This method will return the stack
1298 slot where ``vreg``'s value will be located. If it is necessary to map another
1299 virtual register to the same stack slot, use
1300 ``VirtRegMap::assignVirt2StackSlot(vreg, stack_location)``. One important point
1301 to consider when using the indirect mapping, is that even if a virtual register
1302 is mapped to memory, it still needs to be mapped to a physical register. This
1303 physical register is the location where the virtual register is supposed to be
1304 found before being stored or after being reloaded.
1306 If the indirect strategy is used, after all the virtual registers have been
1307 mapped to physical registers or stack slots, it is necessary to use a spiller
1308 object to place load and store instructions in the code. Every virtual that has
1309 been mapped to a stack slot will be stored to memory after been defined and will
1310 be loaded before being used. The implementation of the spiller tries to recycle
1311 load/store instructions, avoiding unnecessary instructions. For an example of
1312 how to invoke the spiller, see ``RegAllocLinearScan::runOnMachineFunction`` in
1313 ``lib/CodeGen/RegAllocLinearScan.cpp``.
1315 Handling two address instructions
1316 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1318 With very rare exceptions (e.g., function calls), the LLVM machine code
1319 instructions are three address instructions. That is, each instruction is
1320 expected to define at most one register, and to use at most two registers.
1321 However, some architectures use two address instructions. In this case, the
1322 defined register is also one of the used register. For instance, an instruction
1323 such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX +
1326 In order to produce correct code, LLVM must convert three address instructions
1327 that represent two address instructions into true two address instructions. LLVM
1328 provides the pass ``TwoAddressInstructionPass`` for this specific purpose. It
1329 must be run before register allocation takes place. After its execution, the
1330 resulting code may no longer be in SSA form. This happens, for instance, in
1331 situations where an instruction such as ``%a = ADD %b %c`` is converted to two
1332 instructions such as:
1339 Notice that, internally, the second instruction is represented as ``ADD
1340 %a[def/use] %c``. I.e., the register operand ``%a`` is both used and defined by
1343 The SSA deconstruction phase
1344 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1346 An important transformation that happens during register allocation is called
1347 the *SSA Deconstruction Phase*. The SSA form simplifies many analyses that are
1348 performed on the control flow graph of programs. However, traditional
1349 instruction sets do not implement PHI instructions. Thus, in order to generate
1350 executable code, compilers must replace PHI instructions with other instructions
1351 that preserve their semantics.
1353 There are many ways in which PHI instructions can safely be removed from the
1354 target code. The most traditional PHI deconstruction algorithm replaces PHI
1355 instructions with copy instructions. That is the strategy adopted by LLVM. The
1356 SSA deconstruction algorithm is implemented in
1357 ``lib/CodeGen/PHIElimination.cpp``. In order to invoke this pass, the identifier
1358 ``PHIEliminationID`` must be marked as required in the code of the register
1364 *Instruction folding* is an optimization performed during register allocation
1365 that removes unnecessary copy instructions. For instance, a sequence of
1366 instructions such as:
1370 %EBX = LOAD %mem_address
1373 can be safely substituted by the single instruction:
1377 %EAX = LOAD %mem_address
1379 Instructions can be folded with the
1380 ``TargetRegisterInfo::foldMemoryOperand(...)`` method. Care must be taken when
1381 folding instructions; a folded instruction can be quite different from the
1382 original instruction. See ``LiveIntervals::addIntervalsForSpills`` in
1383 ``lib/CodeGen/LiveIntervalAnalysis.cpp`` for an example of its use.
1385 Built in register allocators
1386 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1388 The LLVM infrastructure provides the application developer with three different
1389 register allocators:
1391 * *Fast* --- This register allocator is the default for debug builds. It
1392 allocates registers on a basic block level, attempting to keep values in
1393 registers and reusing registers as appropriate.
1395 * *Basic* --- This is an incremental approach to register allocation. Live
1396 ranges are assigned to registers one at a time in an order that is driven by
1397 heuristics. Since code can be rewritten on-the-fly during allocation, this
1398 framework allows interesting allocators to be developed as extensions. It is
1399 not itself a production register allocator but is a potentially useful
1400 stand-alone mode for triaging bugs and as a performance baseline.
1402 * *Greedy* --- *The default allocator*. This is a highly tuned implementation of
1403 the *Basic* allocator that incorporates global live range splitting. This
1404 allocator works hard to minimize the cost of spill code.
1406 * *PBQP* --- A Partitioned Boolean Quadratic Programming (PBQP) based register
1407 allocator. This allocator works by constructing a PBQP problem representing
1408 the register allocation problem under consideration, solving this using a PBQP
1409 solver, and mapping the solution back to a register assignment.
1411 The type of register allocator used in ``llc`` can be chosen with the command
1412 line option ``-regalloc=...``:
1414 .. code-block:: bash
1416 $ llc -regalloc=linearscan file.bc -o ln.s
1417 $ llc -regalloc=fast file.bc -o fa.s
1418 $ llc -regalloc=pbqp file.bc -o pbqp.s
1420 .. _Prolog/Epilog Code Insertion:
1422 Prolog/Epilog Code Insertion
1423 ----------------------------
1427 Throwing an exception requires *unwinding* out of a function. The information on
1428 how to unwind a given function is traditionally expressed in DWARF unwind
1429 (a.k.a. frame) info. But that format was originally developed for debuggers to
1430 backtrace, and each Frame Description Entry (FDE) requires ~20-30 bytes per
1431 function. There is also the cost of mapping from an address in a function to the
1432 corresponding FDE at runtime. An alternative unwind encoding is called *compact
1433 unwind* and requires just 4-bytes per function.
1435 The compact unwind encoding is a 32-bit value, which is encoded in an
1436 architecture-specific way. It specifies which registers to restore and from
1437 where, and how to unwind out of the function. When the linker creates a final
1438 linked image, it will create a ``__TEXT,__unwind_info`` section. This section is
1439 a small and fast way for the runtime to access unwind info for any given
1440 function. If we emit compact unwind info for the function, that compact unwind
1441 info will be encoded in the ``__TEXT,__unwind_info`` section. If we emit DWARF
1442 unwind info, the ``__TEXT,__unwind_info`` section will contain the offset of the
1443 FDE in the ``__TEXT,__eh_frame`` section in the final linked image.
1445 For X86, there are three modes for the compact unwind encoding:
1447 *Function with a Frame Pointer (``EBP`` or ``RBP``)*
1448 ``EBP/RBP``-based frame, where ``EBP/RBP`` is pushed onto the stack
1449 immediately after the return address, then ``ESP/RSP`` is moved to
1450 ``EBP/RBP``. Thus to unwind, ``ESP/RSP`` is restored with the current
1451 ``EBP/RBP`` value, then ``EBP/RBP`` is restored by popping the stack, and the
1452 return is done by popping the stack once more into the PC. All non-volatile
1453 registers that need to be restored must have been saved in a small range on
1454 the stack that starts ``EBP-4`` to ``EBP-1020`` (``RBP-8`` to
1455 ``RBP-1020``). The offset (divided by 4 in 32-bit mode and 8 in 64-bit mode)
1456 is encoded in bits 16-23 (mask: ``0x00FF0000``). The registers saved are
1457 encoded in bits 0-14 (mask: ``0x00007FFF``) as five 3-bit entries from the
1460 ============== ============= ===============
1461 Compact Number i386 Register x86-64 Register
1462 ============== ============= ===============
1469 ============== ============= ===============
1471 *Frameless with a Small Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)*
1472 To return, a constant (encoded in the compact unwind encoding) is added to the
1473 ``ESP/RSP``. Then the return is done by popping the stack into the PC. All
1474 non-volatile registers that need to be restored must have been saved on the
1475 stack immediately after the return address. The stack size (divided by 4 in
1476 32-bit mode and 8 in 64-bit mode) is encoded in bits 16-23 (mask:
1477 ``0x00FF0000``). There is a maximum stack size of 1024 bytes in 32-bit mode
1478 and 2048 in 64-bit mode. The number of registers saved is encoded in bits 9-12
1479 (mask: ``0x00001C00``). Bits 0-9 (mask: ``0x000003FF``) contain which
1480 registers were saved and their order. (See the
1481 ``encodeCompactUnwindRegistersWithoutFrame()`` function in
1482 ``lib/Target/X86FrameLowering.cpp`` for the encoding algorithm.)
1484 *Frameless with a Large Constant Stack Size (``EBP`` or ``RBP`` is not used as a frame pointer)*
1485 This case is like the "Frameless with a Small Constant Stack Size" case, but
1486 the stack size is too large to encode in the compact unwind encoding. Instead
1487 it requires that the function contains "``subl $nnnnnn, %esp``" in its
1488 prolog. The compact encoding contains the offset to the ``$nnnnnn`` value in
1489 the function in bits 9-12 (mask: ``0x00001C00``).
1491 .. _Late Machine Code Optimizations:
1493 Late Machine Code Optimizations
1494 -------------------------------
1505 The code emission step of code generation is responsible for lowering from the
1506 code generator abstractions (like `MachineFunction`_, `MachineInstr`_, etc) down
1507 to the abstractions used by the MC layer (`MCInst`_, `MCStreamer`_, etc). This
1508 is done with a combination of several different classes: the (misnamed)
1509 target-independent AsmPrinter class, target-specific subclasses of AsmPrinter
1510 (such as SparcAsmPrinter), and the TargetLoweringObjectFile class.
1512 Since the MC layer works at the level of abstraction of object files, it doesn't
1513 have a notion of functions, global variables etc. Instead, it thinks about
1514 labels, directives, and instructions. A key class used at this time is the
1515 MCStreamer class. This is an abstract API that is implemented in different ways
1516 (e.g. to output a .s file, output an ELF .o file, etc) that is effectively an
1517 "assembler API". MCStreamer has one method per directive, such as EmitLabel,
1518 EmitSymbolAttribute, SwitchSection, etc, which directly correspond to assembly
1521 If you are interested in implementing a code generator for a target, there are
1522 three important things that you have to implement for your target:
1524 #. First, you need a subclass of AsmPrinter for your target. This class
1525 implements the general lowering process converting MachineFunction's into MC
1526 label constructs. The AsmPrinter base class provides a number of useful
1527 methods and routines, and also allows you to override the lowering process in
1528 some important ways. You should get much of the lowering for free if you are
1529 implementing an ELF, COFF, or MachO target, because the
1530 TargetLoweringObjectFile class implements much of the common logic.
1532 #. Second, you need to implement an instruction printer for your target. The
1533 instruction printer takes an `MCInst`_ and renders it to a raw_ostream as
1534 text. Most of this is automatically generated from the .td file (when you
1535 specify something like "``add $dst, $src1, $src2``" in the instructions), but
1536 you need to implement routines to print operands.
1538 #. Third, you need to implement code that lowers a `MachineInstr`_ to an MCInst,
1539 usually implemented in "<target>MCInstLower.cpp". This lowering process is
1540 often target specific, and is responsible for turning jump table entries,
1541 constant pool indices, global variable addresses, etc into MCLabels as
1542 appropriate. This translation layer is also responsible for expanding pseudo
1543 ops used by the code generator into the actual machine instructions they
1544 correspond to. The MCInsts that are generated by this are fed into the
1545 instruction printer or the encoder.
1547 Finally, at your choosing, you can also implement an subclass of MCCodeEmitter
1548 which lowers MCInst's into machine code bytes and relocations. This is
1549 important if you want to support direct .o file emission, or would like to
1550 implement an assembler for your target.
1555 In a Very Long Instruction Word (VLIW) architecture, the compiler is responsible
1556 for mapping instructions to functional-units available on the architecture. To
1557 that end, the compiler creates groups of instructions called *packets* or
1558 *bundles*. The VLIW packetizer in LLVM is a target-independent mechanism to
1559 enable the packetization of machine instructions.
1561 Mapping from instructions to functional units
1562 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1564 Instructions in a VLIW target can typically be mapped to multiple functional
1565 units. During the process of packetizing, the compiler must be able to reason
1566 about whether an instruction can be added to a packet. This decision can be
1567 complex since the compiler has to examine all possible mappings of instructions
1568 to functional units. Therefore to alleviate compilation-time complexity, the
1569 VLIW packetizer parses the instruction classes of a target and generates tables
1570 at compiler build time. These tables can then be queried by the provided
1571 machine-independent API to determine if an instruction can be accommodated in a
1574 How the packetization tables are generated and used
1575 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1577 The packetizer reads instruction classes from a target's itineraries and creates
1578 a deterministic finite automaton (DFA) to represent the state of a packet. A DFA
1579 consists of three major elements: inputs, states, and transitions. The set of
1580 inputs for the generated DFA represents the instruction being added to a
1581 packet. The states represent the possible consumption of functional units by
1582 instructions in a packet. In the DFA, transitions from one state to another
1583 occur on the addition of an instruction to an existing packet. If there is a
1584 legal mapping of functional units to instructions, then the DFA contains a
1585 corresponding transition. The absence of a transition indicates that a legal
1586 mapping does not exist and that the instruction cannot be added to the packet.
1588 To generate tables for a VLIW target, add *Target*\ GenDFAPacketizer.inc as a
1589 target to the Makefile in the target directory. The exported API provides three
1590 functions: ``DFAPacketizer::clearResources()``,
1591 ``DFAPacketizer::reserveResources(MachineInstr *MI)``, and
1592 ``DFAPacketizer::canReserveResources(MachineInstr *MI)``. These functions allow
1593 a target packetizer to add an instruction to an existing packet and to check
1594 whether an instruction can be added to a packet. See
1595 ``llvm/CodeGen/DFAPacketizer.h`` for more information.
1597 Implementing a Native Assembler
1598 ===============================
1600 Though you're probably reading this because you want to write or maintain a
1601 compiler backend, LLVM also fully supports building a native assemblers too.
1602 We've tried hard to automate the generation of the assembler from the .td files
1603 (in particular the instruction syntax and encodings), which means that a large
1604 part of the manual and repetitive data entry can be factored and shared with the
1615 Instruction Alias Processing
1616 ----------------------------
1618 Once the instruction is parsed, it enters the MatchInstructionImpl function.
1619 The MatchInstructionImpl function performs alias processing and then does actual
1622 Alias processing is the phase that canonicalizes different lexical forms of the
1623 same instructions down to one representation. There are several different kinds
1624 of alias that are possible to implement and they are listed below in the order
1625 that they are processed (which is in order from simplest/weakest to most
1626 complex/powerful). Generally you want to use the first alias mechanism that
1627 meets the needs of your instruction, because it will allow a more concise
1633 The first phase of alias processing is simple instruction mnemonic remapping for
1634 classes of instructions which are allowed with two different mnemonics. This
1635 phase is a simple and unconditionally remapping from one input mnemonic to one
1636 output mnemonic. It isn't possible for this form of alias to look at the
1637 operands at all, so the remapping must apply for all forms of a given mnemonic.
1638 Mnemonic aliases are defined simply, for example X86 has:
1642 def : MnemonicAlias<"cbw", "cbtw">;
1643 def : MnemonicAlias<"smovq", "movsq">;
1644 def : MnemonicAlias<"fldcww", "fldcw">;
1645 def : MnemonicAlias<"fucompi", "fucomip">;
1646 def : MnemonicAlias<"ud2a", "ud2">;
1648 ... and many others. With a MnemonicAlias definition, the mnemonic is remapped
1649 simply and directly. Though MnemonicAlias's can't look at any aspect of the
1650 instruction (such as the operands) they can depend on global modes (the same
1651 ones supported by the matcher), through a Requires clause:
1655 def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
1656 def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;
1658 In this example, the mnemonic gets mapped into different a new one depending on
1659 the current instruction set.
1664 The most general phase of alias processing occurs while matching is happening:
1665 it provides new forms for the matcher to match along with a specific instruction
1666 to generate. An instruction alias has two parts: the string to match and the
1667 instruction to generate. For example:
1671 def : InstAlias<"movsx $src, $dst", (MOVSX16rr8W GR16:$dst, GR8 :$src)>;
1672 def : InstAlias<"movsx $src, $dst", (MOVSX16rm8W GR16:$dst, i8mem:$src)>;
1673 def : InstAlias<"movsx $src, $dst", (MOVSX32rr8 GR32:$dst, GR8 :$src)>;
1674 def : InstAlias<"movsx $src, $dst", (MOVSX32rr16 GR32:$dst, GR16 :$src)>;
1675 def : InstAlias<"movsx $src, $dst", (MOVSX64rr8 GR64:$dst, GR8 :$src)>;
1676 def : InstAlias<"movsx $src, $dst", (MOVSX64rr16 GR64:$dst, GR16 :$src)>;
1677 def : InstAlias<"movsx $src, $dst", (MOVSX64rr32 GR64:$dst, GR32 :$src)>;
1679 This shows a powerful example of the instruction aliases, matching the same
1680 mnemonic in multiple different ways depending on what operands are present in
1681 the assembly. The result of instruction aliases can include operands in a
1682 different order than the destination instruction, and can use an input multiple
1687 def : InstAlias<"clrb $reg", (XOR8rr GR8 :$reg, GR8 :$reg)>;
1688 def : InstAlias<"clrw $reg", (XOR16rr GR16:$reg, GR16:$reg)>;
1689 def : InstAlias<"clrl $reg", (XOR32rr GR32:$reg, GR32:$reg)>;
1690 def : InstAlias<"clrq $reg", (XOR64rr GR64:$reg, GR64:$reg)>;
1692 This example also shows that tied operands are only listed once. In the X86
1693 backend, XOR8rr has two input GR8's and one output GR8 (where an input is tied
1694 to the output). InstAliases take a flattened operand list without duplicates
1695 for tied operands. The result of an instruction alias can also use immediates
1696 and fixed physical registers which are added as simple immediate operands in the
1697 result, for example:
1701 // Fixed Immediate operand.
1702 def : InstAlias<"aad", (AAD8i8 10)>;
1704 // Fixed register operand.
1705 def : InstAlias<"fcomi", (COM_FIr ST1)>;
1708 def : InstAlias<"fcomi $reg", (COM_FIr RST:$reg)>;
1710 Instruction aliases can also have a Requires clause to make them subtarget
1713 If the back-end supports it, the instruction printer can automatically emit the
1714 alias rather than what's being aliased. It typically leads to better, more
1715 readable code. If it's better to print out what's being aliased, then pass a '0'
1716 as the third parameter to the InstAlias definition.
1718 Instruction Matching
1719 --------------------
1725 .. _Implementations of the abstract target description interfaces:
1726 .. _implement the target description:
1728 Target-specific Implementation Notes
1729 ====================================
1731 This section of the document explains features or design decisions that are
1732 specific to the code generator for a particular target. First we start with a
1733 table that summarizes what features are supported by each target.
1735 .. _target-feature-matrix:
1737 Target Feature Matrix
1738 ---------------------
1740 Note that this table does not include the C backend or Cpp backends, since they
1741 do not use the target independent code generator infrastructure. It also
1742 doesn't list features that are not supported fully by any target yet. It
1743 considers a feature to be supported if at least one subtarget supports it. A
1744 feature being supported means that it is useful and works for most cases, it
1745 does not indicate that there are zero known bugs in the implementation. Here is
1748 :raw-html:`<table border="1" cellspacing="0">`
1750 :raw-html:`<th>Unknown</th>`
1751 :raw-html:`<th>No support</th>`
1752 :raw-html:`<th>Partial Support</th>`
1753 :raw-html:`<th>Complete Support</th>`
1756 :raw-html:`<td class="unknown"></td>`
1757 :raw-html:`<td class="no"></td>`
1758 :raw-html:`<td class="partial"></td>`
1759 :raw-html:`<td class="yes"></td>`
1761 :raw-html:`</table>`
1765 :raw-html:`<table width="689" border="1" cellspacing="0">`
1766 :raw-html:`<tr><td></td>`
1767 :raw-html:`<td colspan="13" align="center" style="background-color:#ffc">Target</td>`
1770 :raw-html:`<th>Feature</th>`
1771 :raw-html:`<th>ARM</th>`
1772 :raw-html:`<th>Hexagon</th>`
1773 :raw-html:`<th>MBlaze</th>`
1774 :raw-html:`<th>MSP430</th>`
1775 :raw-html:`<th>Mips</th>`
1776 :raw-html:`<th>PTX</th>`
1777 :raw-html:`<th>PowerPC</th>`
1778 :raw-html:`<th>Sparc</th>`
1779 :raw-html:`<th>X86</th>`
1780 :raw-html:`<th>XCore</th>`
1784 :raw-html:`<td><a href="#feat_reliable">is generally reliable</a></td>`
1785 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1786 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
1787 :raw-html:`<td class="no"></td> <!-- MBlaze -->`
1788 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1789 :raw-html:`<td class="yes"></td> <!-- Mips -->`
1790 :raw-html:`<td class="no"></td> <!-- PTX -->`
1791 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1792 :raw-html:`<td class="yes"></td> <!-- Sparc -->`
1793 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1794 :raw-html:`<td class="unknown"></td> <!-- XCore -->`
1798 :raw-html:`<td><a href="#feat_asmparser">assembly parser</a></td>`
1799 :raw-html:`<td class="no"></td> <!-- ARM -->`
1800 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1801 :raw-html:`<td class="yes"></td> <!-- MBlaze -->`
1802 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1803 :raw-html:`<td class="no"></td> <!-- Mips -->`
1804 :raw-html:`<td class="no"></td> <!-- PTX -->`
1805 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1806 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1807 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1808 :raw-html:`<td class="no"></td> <!-- XCore -->`
1812 :raw-html:`<td><a href="#feat_disassembler">disassembler</a></td>`
1813 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1814 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1815 :raw-html:`<td class="yes"></td> <!-- MBlaze -->`
1816 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1817 :raw-html:`<td class="no"></td> <!-- Mips -->`
1818 :raw-html:`<td class="no"></td> <!-- PTX -->`
1819 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1820 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1821 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1822 :raw-html:`<td class="no"></td> <!-- XCore -->`
1826 :raw-html:`<td><a href="#feat_inlineasm">inline asm</a></td>`
1827 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1828 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
1829 :raw-html:`<td class="yes"></td> <!-- MBlaze -->`
1830 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1831 :raw-html:`<td class="no"></td> <!-- Mips -->`
1832 :raw-html:`<td class="unknown"></td> <!-- PTX -->`
1833 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1834 :raw-html:`<td class="unknown"></td> <!-- Sparc -->`
1835 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1836 :raw-html:`<td class="unknown"></td> <!-- XCore -->`
1840 :raw-html:`<td><a href="#feat_jit">jit</a></td>`
1841 :raw-html:`<td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->`
1842 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1843 :raw-html:`<td class="no"></td> <!-- MBlaze -->`
1844 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1845 :raw-html:`<td class="yes"></td> <!-- Mips -->`
1846 :raw-html:`<td class="unknown"></td> <!-- PTX -->`
1847 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1848 :raw-html:`<td class="unknown"></td> <!-- Sparc -->`
1849 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1850 :raw-html:`<td class="unknown"></td> <!-- XCore -->`
1854 :raw-html:`<td><a href="#feat_objectwrite">.o file writing</a></td>`
1855 :raw-html:`<td class="no"></td> <!-- ARM -->`
1856 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1857 :raw-html:`<td class="yes"></td> <!-- MBlaze -->`
1858 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1859 :raw-html:`<td class="no"></td> <!-- Mips -->`
1860 :raw-html:`<td class="no"></td> <!-- PTX -->`
1861 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1862 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1863 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1864 :raw-html:`<td class="no"></td> <!-- XCore -->`
1868 :raw-html:`<td><a hr:raw-html:`ef="#feat_tailcall">tail calls</a></td>`
1869 :raw-html:`<td class="yes"></td> <!-- ARM -->`
1870 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
1871 :raw-html:`<td class="no"></td> <!-- MBlaze -->`
1872 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
1873 :raw-html:`<td class="no"></td> <!-- Mips -->`
1874 :raw-html:`<td class="unknown"></td> <!-- PTX -->`
1875 :raw-html:`<td class="yes"></td> <!-- PowerPC -->`
1876 :raw-html:`<td class="unknown"></td> <!-- Sparc -->`
1877 :raw-html:`<td class="yes"></td> <!-- X86 -->`
1878 :raw-html:`<td class="unknown"></td> <!-- XCore -->`
1882 :raw-html:`<td><a href="#feat_segstacks">segmented stacks</a></td>`
1883 :raw-html:`<td class="no"></td> <!-- ARM -->`
1884 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
1885 :raw-html:`<td class="no"></td> <!-- MBlaze -->`
1886 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
1887 :raw-html:`<td class="no"></td> <!-- Mips -->`
1888 :raw-html:`<td class="no"></td> <!-- PTX -->`
1889 :raw-html:`<td class="no"></td> <!-- PowerPC -->`
1890 :raw-html:`<td class="no"></td> <!-- Sparc -->`
1891 :raw-html:`<td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 -->`
1892 :raw-html:`<td class="no"></td> <!-- XCore -->`
1895 :raw-html:`</table>`
1899 Is Generally Reliable
1900 ^^^^^^^^^^^^^^^^^^^^^
1902 This box indicates whether the target is considered to be production quality.
1903 This indicates that the target has been used as a static compiler to compile
1904 large amounts of code by a variety of different people and is in continuous use.
1911 This box indicates whether the target supports parsing target specific .s files
1912 by implementing the MCAsmParser interface. This is required for llvm-mc to be
1913 able to act as a native assembler and is required for inline assembly support in
1914 the native .o file writer.
1916 .. _feat_disassembler:
1921 This box indicates whether the target supports the MCDisassembler API for
1922 disassembling machine opcode bytes into MCInst's.
1929 This box indicates whether the target supports most popular inline assembly
1930 constraints and modifiers.
1937 This box indicates whether the target supports the JIT compiler through the
1938 ExecutionEngine interface.
1942 The ARM backend has basic support for integer code in ARM codegen mode, but
1943 lacks NEON and full Thumb support.
1945 .. _feat_objectwrite:
1950 This box indicates whether the target supports writing .o files (e.g. MachO,
1951 ELF, and/or COFF) files directly from the target. Note that the target also
1952 must include an assembly parser and general inline assembly support for full
1953 inline assembly support in the .o writer.
1955 Targets that don't support this feature can obviously still write out .o files,
1956 they just rely on having an external assembler to translate from a .s file to a
1957 .o file (as is the case for many C compilers).
1964 This box indicates whether the target supports guaranteed tail calls. These are
1965 calls marked "`tail <LangRef.html#i_call>`_" and use the fastcc calling
1966 convention. Please see the `tail call section more more details`_.
1973 This box indicates whether the target supports segmented stacks. This replaces
1974 the traditional large C stack with many linked segments. It is compatible with
1975 the `gcc implementation <http://gcc.gnu.org/wiki/SplitStacks>`_ used by the Go
1978 .. _feat_segstacks_x86:
1980 Basic support exists on the X86 backend. Currently vararg doesn't work and the
1981 object files are not marked the way the gold linker expects, but simple Go
1982 programs can be built by dragonegg.
1984 .. _tail call section more more details:
1986 Tail call optimization
1987 ----------------------
1989 Tail call optimization, callee reusing the stack of the caller, is currently
1990 supported on x86/x86-64 and PowerPC. It is performed if:
1992 * Caller and callee have the calling convention ``fastcc``, ``cc 10`` (GHC
1993 calling convention) or ``cc 11`` (HiPE calling convention).
1995 * The call is a tail call - in tail position (ret immediately follows call and
1996 ret uses value of call or is void).
1998 * Option ``-tailcallopt`` is enabled.
2000 * Platform specific constraints are met.
2002 x86/x86-64 constraints:
2004 * No variable argument lists are used.
2006 * On x86-64 when generating GOT/PIC code only module-local calls (visibility =
2007 hidden or protected) are supported.
2009 PowerPC constraints:
2011 * No variable argument lists are used.
2013 * No byval parameters are used.
2015 * On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected)
2020 Call as ``llc -tailcallopt test.ll``.
2022 .. code-block:: llvm
2024 declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
2026 define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
2027 %l1 = add i32 %in1, %in2
2028 %tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
2032 Implications of ``-tailcallopt``:
2034 To support tail call optimization in situations where the callee has more
2035 arguments than the caller a 'callee pops arguments' convention is used. This
2036 currently causes each ``fastcc`` call that is not tail call optimized (because
2037 one or more of above constraints are not met) to be followed by a readjustment
2038 of the stack. So performance might be worse in such cases.
2040 Sibling call optimization
2041 -------------------------
2043 Sibling call optimization is a restricted form of tail call optimization.
2044 Unlike tail call optimization described in the previous section, it can be
2045 performed automatically on any tail calls when ``-tailcallopt`` option is not
2048 Sibling call optimization is currently performed on x86/x86-64 when the
2049 following constraints are met:
2051 * Caller and callee have the same calling convention. It can be either ``c`` or
2054 * The call is a tail call - in tail position (ret immediately follows call and
2055 ret uses value of call or is void).
2057 * Caller and callee have matching return type or the callee result is not used.
2059 * If any of the callee arguments are being passed in stack, they must be
2060 available in caller's own incoming argument stack and the frame offsets must
2065 .. code-block:: llvm
2067 declare i32 @bar(i32, i32)
2069 define i32 @foo(i32 %a, i32 %b, i32 %c) {
2071 %0 = tail call i32 @bar(i32 %a, i32 %b)
2078 The X86 code generator lives in the ``lib/Target/X86`` directory. This code
2079 generator is capable of targeting a variety of x86-32 and x86-64 processors, and
2080 includes support for ISA extensions such as MMX and SSE.
2082 X86 Target Triples supported
2083 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2085 The following are the known target triples that are supported by the X86
2086 backend. This is not an exhaustive list, and it would be useful to add those
2089 * **i686-pc-linux-gnu** --- Linux
2091 * **i386-unknown-freebsd5.3** --- FreeBSD 5.3
2093 * **i686-pc-cygwin** --- Cygwin on Win32
2095 * **i686-pc-mingw32** --- MingW on Win32
2097 * **i386-pc-mingw32msvc** --- MingW crosscompiler on Linux
2099 * **i686-apple-darwin*** --- Apple Darwin on X86
2101 * **x86_64-unknown-linux-gnu** --- Linux
2103 X86 Calling Conventions supported
2104 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2106 The following target-specific calling conventions are known to backend:
2108 * **x86_StdCall** --- stdcall calling convention seen on Microsoft Windows
2109 platform (CC ID = 64).
2111 * **x86_FastCall** --- fastcall calling convention seen on Microsoft Windows
2112 platform (CC ID = 65).
2114 * **x86_ThisCall** --- Similar to X86_StdCall. Passes first argument in ECX,
2115 others via stack. Callee is responsible for stack cleaning. This convention is
2116 used by MSVC by default for methods in its ABI (CC ID = 70).
2118 .. _X86 addressing mode:
2120 Representing X86 addressing modes in MachineInstrs
2121 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2123 The x86 has a very flexible way of accessing memory. It is capable of forming
2124 memory addresses of the following expression directly in integer instructions
2125 (which use ModR/M addressing):
2129 SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32
2131 In order to represent this, LLVM tracks no less than 5 operands for each memory
2132 operand of this form. This means that the "load" form of '``mov``' has the
2133 following ``MachineOperand``\s in this order:
2137 Index: 0 | 1 2 3 4 5
2138 Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement Segment
2139 OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg
2141 Stores, and all other instructions, treat the four memory operands in the same
2142 way and in the same order. If the segment register is unspecified (regno = 0),
2143 then no segment override is generated. "Lea" operations do not have a segment
2144 register specified, so they only have 4 operands for their memory reference.
2146 X86 address spaces supported
2147 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2149 x86 has a feature which provides the ability to perform loads and stores to
2150 different address spaces via the x86 segment registers. A segment override
2151 prefix byte on an instruction causes the instruction's memory access to go to
2152 the specified segment. LLVM address space 0 is the default address space, which
2153 includes the stack, and any unqualified memory accesses in a program. Address
2154 spaces 1-255 are currently reserved for user-defined code. The GS-segment is
2155 represented by address space 256, while the FS-segment is represented by address
2156 space 257. Other x86 segments have yet to be allocated address space
2159 While these address spaces may seem similar to TLS via the ``thread_local``
2160 keyword, and often use the same underlying hardware, there are some fundamental
2163 The ``thread_local`` keyword applies to global variables and specifies that they
2164 are to be allocated in thread-local memory. There are no type qualifiers
2165 involved, and these variables can be pointed to with normal pointers and
2166 accessed with normal loads and stores. The ``thread_local`` keyword is
2167 target-independent at the LLVM IR level (though LLVM doesn't yet have
2168 implementations of it for some configurations)
2170 Special address spaces, in contrast, apply to static types. Every load and store
2171 has a particular address space in its address operand type, and this is what
2172 determines which address space is accessed. LLVM ignores these special address
2173 space qualifiers on global variables, and does not provide a way to directly
2174 allocate storage in them. At the LLVM IR level, the behavior of these special
2175 address spaces depends in part on the underlying OS or runtime environment, and
2176 they are specific to x86 (and LLVM doesn't yet handle them correctly in some
2179 Some operating systems and runtime environments use (or may in the future use)
2180 the FS/GS-segment registers for various low-level purposes, so care should be
2181 taken when considering them.
2186 An instruction name consists of the base name, a default operand size, and a a
2187 character per operand with an optional special size. For example:
2191 ADD8rr -> add, 8-bit register, 8-bit register
2192 IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
2193 IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
2194 MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
2199 The PowerPC code generator lives in the lib/Target/PowerPC directory. The code
2200 generation is retargetable to several variations or *subtargets* of the PowerPC
2201 ISA; including ppc32, ppc64 and altivec.
2206 LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC relative
2207 (PIC) or static addressing for accessing global values, so no TOC (r2) is
2208 used. Second, r31 is used as a frame pointer to allow dynamic growth of a stack
2209 frame. LLVM takes advantage of having no TOC to provide space to save the frame
2210 pointer in the PowerPC linkage area of the caller frame. Other details of
2211 PowerPC ABI can be found at `PowerPC ABI
2212 <http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html>`_\
2213 . Note: This link describes the 32 bit ABI. The 64 bit ABI is similar except
2214 space for GPRs are 8 bytes wide (not 4) and r13 is reserved for system use.
2219 The size of a PowerPC frame is usually fixed for the duration of a function's
2220 invocation. Since the frame is fixed size, all references into the frame can be
2221 accessed via fixed offsets from the stack pointer. The exception to this is
2222 when dynamic alloca or variable sized arrays are present, then a base pointer
2223 (r31) is used as a proxy for the stack pointer and stack pointer is free to grow
2224 or shrink. A base pointer is also used if llvm-gcc is not passed the
2225 -fomit-frame-pointer flag. The stack pointer is always aligned to 16 bytes, so
2226 that space allocated for altivec vectors will be properly aligned.
2228 An invocation frame is laid out as follows (low memory at top):
2230 :raw-html:`<table border="1" cellspacing="0">`
2232 :raw-html:`<td>Linkage<br><br></td>`
2235 :raw-html:`<td>Parameter area<br><br></td>`
2238 :raw-html:`<td>Dynamic area<br><br></td>`
2241 :raw-html:`<td>Locals area<br><br></td>`
2244 :raw-html:`<td>Saved registers area<br><br></td>`
2246 :raw-html:`<tr style="border-style: none hidden none hidden;">`
2247 :raw-html:`<td><br></td>`
2250 :raw-html:`<td>Previous Frame<br><br></td>`
2252 :raw-html:`</table>`
2254 The *linkage* area is used by a callee to save special registers prior to
2255 allocating its own frame. Only three entries are relevant to LLVM. The first
2256 entry is the previous stack pointer (sp), aka link. This allows probing tools
2257 like gdb or exception handlers to quickly scan the frames in the stack. A
2258 function epilog can also use the link to pop the frame from the stack. The
2259 third entry in the linkage area is used to save the return address from the lr
2260 register. Finally, as mentioned above, the last entry is used to save the
2261 previous frame pointer (r31.) The entries in the linkage area are the size of a
2262 GPR, thus the linkage area is 24 bytes long in 32 bit mode and 48 bytes in 64
2265 32 bit linkage area:
2267 :raw-html:`<table border="1" cellspacing="0">`
2269 :raw-html:`<td>0</td>`
2270 :raw-html:`<td>Saved SP (r1)</td>`
2273 :raw-html:`<td>4</td>`
2274 :raw-html:`<td>Saved CR</td>`
2277 :raw-html:`<td>8</td>`
2278 :raw-html:`<td>Saved LR</td>`
2281 :raw-html:`<td>12</td>`
2282 :raw-html:`<td>Reserved</td>`
2285 :raw-html:`<td>16</td>`
2286 :raw-html:`<td>Reserved</td>`
2289 :raw-html:`<td>20</td>`
2290 :raw-html:`<td>Saved FP (r31)</td>`
2292 :raw-html:`</table>`
2294 64 bit linkage area:
2296 :raw-html:`<table border="1" cellspacing="0">`
2298 :raw-html:`<td>0</td>`
2299 :raw-html:`<td>Saved SP (r1)</td>`
2302 :raw-html:`<td>8</td>`
2303 :raw-html:`<td>Saved CR</td>`
2306 :raw-html:`<td>16</td>`
2307 :raw-html:`<td>Saved LR</td>`
2310 :raw-html:`<td>24</td>`
2311 :raw-html:`<td>Reserved</td>`
2314 :raw-html:`<td>32</td>`
2315 :raw-html:`<td>Reserved</td>`
2318 :raw-html:`<td>40</td>`
2319 :raw-html:`<td>Saved FP (r31)</td>`
2321 :raw-html:`</table>`
2323 The *parameter area* is used to store arguments being passed to a callee
2324 function. Following the PowerPC ABI, the first few arguments are actually
2325 passed in registers, with the space in the parameter area unused. However, if
2326 there are not enough registers or the callee is a thunk or vararg function,
2327 these register arguments can be spilled into the parameter area. Thus, the
2328 parameter area must be large enough to store all the parameters for the largest
2329 call sequence made by the caller. The size must also be minimally large enough
2330 to spill registers r3-r10. This allows callees blind to the call signature,
2331 such as thunks and vararg functions, enough space to cache the argument
2332 registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64
2333 bit mode.) Also note that since the parameter area is a fixed offset from the
2334 top of the frame, that a callee can access its spilt arguments using fixed
2335 offsets from the stack pointer (or base pointer.)
2337 Combining the information about the linkage, parameter areas and alignment. A
2338 stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit mode.
2340 The *dynamic area* starts out as size zero. If a function uses dynamic alloca
2341 then space is added to the stack, the linkage and parameter areas are shifted to
2342 top of stack, and the new space is available immediately below the linkage and
2343 parameter areas. The cost of shifting the linkage and parameter areas is minor
2344 since only the link value needs to be copied. The link value can be easily
2345 fetched by adding the original frame size to the base pointer. Note that
2346 allocations in the dynamic space need to observe 16 byte alignment.
2348 The *locals area* is where the llvm compiler reserves space for local variables.
2350 The *saved registers area* is where the llvm compiler spills callee saved
2351 registers on entry to the callee.
2356 The llvm prolog and epilog are the same as described in the PowerPC ABI, with
2357 the following exceptions. Callee saved registers are spilled after the frame is
2358 created. This allows the llvm epilog/prolog support to be common with other
2359 targets. The base pointer callee saved register r31 is saved in the TOC slot of
2360 linkage area. This simplifies allocation of space for the base pointer and
2361 makes it convenient to locate programatically and during debugging.
2368 TODO - More to come.
2373 The PTX code generator lives in the lib/Target/PTX directory. It is currently a
2374 work-in-progress, but already supports most of the code generation functionality
2375 needed to generate correct PTX kernels for CUDA devices.
2377 The code generator can target PTX 2.0+, and shader model 1.0+. The PTX ISA
2378 Reference Manual is used as the primary source of ISA information, though an
2379 effort is made to make the output of the code generator match the output of the
2380 NVidia nvcc compiler, whenever possible.
2382 Code Generator Options:
2384 :raw-html:`<table border="1" cellspacing="0">`
2386 :raw-html:`<th>Option</th>`
2387 :raw-html:`<th>Description</th>`
2390 :raw-html:`<td>``double``</td>`
2391 :raw-html:`<td align="left">If enabled, the map_f64_to_f32 directive is disabled in the PTX output, allowing native double-precision arithmetic</td>`
2394 :raw-html:`<td>``no-fma``</td>`
2395 :raw-html:`<td align="left">Disable generation of Fused-Multiply Add instructions, which may be beneficial for some devices</td>`
2398 :raw-html:`<td>``smxy / computexy``</td>`
2399 :raw-html:`<td align="left">Set shader model/compute capability to x.y, e.g. sm20 or compute13</td>`
2401 :raw-html:`</table>`
2405 * Arithmetic instruction selection (including combo FMA)
2407 * Bitwise instruction selection
2409 * Control-flow instruction selection
2411 * Function calls (only on SM 2.0+ and no return arguments)
2413 * Addresses spaces (0 = global, 1 = constant, 2 = local, 4 = shared)
2415 * Thread synchronization (bar.sync)
2417 * Special register reads ([N]TID, [N]CTAID, PMx, CLOCK, etc.)
2421 * Robust call instruction selection
2423 * Stack frame allocation
2425 * Device-specific instruction scheduling optimizations