lib/Target/X86/README.txt

   1 //===- README.txt - Information about the X86 backend and related files ---===//
   2 //
   3 // This file contains random notes and points of interest about the X86 backend.
   4 //
   5 //===----------------------------------------------------------------------===//
   6
   7 ===========
   8 I. Overview
   9 ===========
  10
  11 This directory contains a machine description for the X86 processor family.
  12 Currently this machine description is used for a high performance code generator
  13 used by the LLVM JIT and static code generators.  One of the main objectives
  14 that we would like to support with this project is to build a nice clean code
  15 generator that may be extended in the future in a variety of ways: new targets,
  16 new optimizations, new transformations, etc.
  17
  18 This document describes the current state of the X86 code generator, along with
  19 implementation notes, design decisions, and other stuff.
  20
  21
  22 ===================================
  23 II. Architecture / Design Decisions
  24 ===================================
  25
  26 We designed the infrastructure into the generic LLVM machine specific
  27 representation, which allows us to support as many targets as possible with our
  28 framework.  This framework should allow us to share many common machine specific
  29 transformations (register allocation, instruction scheduling, etc...) among all
  30 of the backends that may eventually be supported by LLVM, and ensures that the
  31 JIT and static compiler backends are largely shared.
  32
  33 At the high-level, LLVM code is translated to a machine specific representation
  34 formed out of MachineFunction, MachineBasicBlock, and MachineInstr instances
  35 (defined in include/llvm/CodeGen).  This representation is completely target
  36 agnostic, representing instructions in their most abstract form: an opcode and a
  37 series of operands.  This representation is designed to support both SSA
  38 representation for machine code, as well as a register allocated, non-SSA form.
  39
  40 Because the Machine* representation must work regardless of the target machine,
  41 it contains very little semantic information about the program.  To get semantic
  42 information about the program, a layer of Target description datastructures are
  43 used, defined in include/llvm/Target.
  44
  45 Note that there is some amount of complexity that the X86 backend contains due
  46 to the Sparc backend's legacy requirements.  These should eventually fade away
  47 as the project progresses.
  48
  49
  50 SSA Instruction Representation
  51 ------------------------------
  52 Target machine instructions are represented as instances of MachineInstr, and
  53 all specific machine instruction types should have an entry in the
  54 X86InstrInfo.td file.  In the X86 backend, there are two particularly
  55 interesting forms of machine instruction: those that produce a value (such as
  56 add), and those that do not (such as a store).
  57
  58 Instructions that produce a value use Operand #0 as the "destination" register.
  59 When printing the assembly code with the built-in machine instruction printer,
  60 these destination registers will be printed to the left side of an '=' sign, as
  61 in: %reg1027 = add %reg1026, %reg1025
  62
  63 This `add' MachineInstruction contains three "operands": the first is the
  64 destination register (#1027), the second is the first source register (#1026)
  65 and the third is the second source register (#1025).  Never forget the
  66 destination register will show up in the MachineInstr operands vector.  The code
  67 to generate this instruction looks like this:
  68
  69   BuildMI(BB, X86::ADD32rr, 2, 1027).addReg(1026).addReg(1025);
  70
  71 The first argument to BuildMI is the basic block to append the machine
  72 instruction to, the second is the opcode, the third is the number of operands,
  73 the fourth is the destination register.  The two addReg calls specify operands
  74 in order.
  75
  76 MachineInstrs that do not produce a value do not have this implicit first
  77 operand, they simply have #operands = #uses.  To create them, simply do not
  78 specify a destination register to the BuildMI call.
  79
  80
  81 ======================
  82 IV. Source Code Layout
  83 ======================
  84
  85 The LLVM code generator is composed of source files primarily in the following
  86 locations:
  87
  88 include/llvm/CodeGen
  89 --------------------
  90 This directory contains header files that are used to represent the program in a
  91 machine specific representation.  It currently also contains a bunch of stuff
  92 used by the Sparc backend that we don't want to get mixed up in, such as
  93 register allocation internals.
  94
  95 include/llvm/Target
  96 -------------------
  97 This directory contains header files that are used to interpret the machine
  98 specific representation of the program.  This allows us to write generic
  99 transformations that will work on any target that implements the interfaces
 100 defined in this directory.  The only classes used by the X86 backend so far are
 101 the TargetMachine, TargetData, MachineInstrInfo, and MRegisterInfo classes.
 102
 103 lib/CodeGen
 104 -----------
 105 This directory will contain all of the target independent transformations (for
 106 example, register allocation) that we write.  These transformations should only
 107 use information exposed through the Target interface, they should not include
 108 any target specific header files.
 109
 110 lib/Target/X86
 111 --------------
 112 This directory contains the machine description for X86 that is required to the
 113 rest of the compiler working.  It contains any code that is truly specific to
 114 the X86 backend, for example the instruction selector and machine code emitter.
 115
 116 lib/ExecutionEngine/JIT
 117 -----------------------
 118 This directory contains the top-level code for the JIT compiler.  This code
 119 basically boils down to a call to TargetMachine::addPassesToJITCompile, and
 120 handles the compile-dispatch-recompile cycle.
 121
 122 test/Regression/CodeGen/X86
 123 ---------------------------
 124 This directory contains regression tests for the X86 code generator.
 125
 126
 127 ==================================================
 128 V. Strange Things, or, Things That Should Be Known
 129 ==================================================
 130
 131 Representing memory in MachineInstrs
 132 ------------------------------------
 133
 134 The x86 has a very, uhm, flexible, way of accessing memory.  It is capable of
 135 addressing memory addresses of the following form directly in integer
 136 instructions (which use ModR/M addressing):
 137
 138    Base+[1,2,4,8]*IndexReg+Disp32
 139
 140 Wow, that's crazy.  In order to represent this, LLVM tracks no less that 4
 141 operands for each memory operand of this form.  This means that the "load" form
 142 of 'mov' has the following "Operands" in this order:
 143
 144 Index:        0     |    1        2       3           4
 145 Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement
 146 OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm
 147
 148 Stores and all other instructions treat the four memory operands in the same
 149 way, in the same order.
 150
 151
 152 ======================
 153 VI. Instruction naming
 154 ======================
 155
 156 An instruction name consists of the base name, a default operand size
 157 followed by a character per operand with an optional special size. For
 158 example:
 159
 160 ADD8rr -> add, 8-bit register, 8-bit register
 161
 162 IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
 163
 164 IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
 165
 166 MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
 167
 168
 169 ==========================
 170 VII. TODO / Future Projects
 171 ==========================
 172
 173 Ideas for Improvements:
 174 -----------------------
 175 1. Implement an *optimal* linear time instruction selector
 176 2. Implement lots of nifty runtime optimizations
 177 3. Implement new targets: IA64? X86-64? M68k? MMIX?  Who knows...
 178
 179 Infrastructure Improvements:
 180 ----------------------------
 181
 182 1. X86/Printer.cpp and Sparc/EmitAssembly.cpp both have copies of what is
 183    roughly the same code, used to output constants in a form the assembler
 184    can understand. These functions should be shared at some point. They
 185    should be rewritten to pass around iostreams instead of strings. The
 186    list of functions is as follows:
 187
 188    isStringCompatible
 189    toOctal
 190    ConstantExprToString
 191    valToExprString
 192    getAsCString
 193    printSingleConstantValue (with TypeToDataDirective inlined)
 194    printConstantValueOnly