From 994d7ae649f6b1d11015d1c295bd656772c5b734 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Fri, 4 Jun 2004 00:15:21 +0000 Subject: [PATCH] This file is obsolete git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14005 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Target/X86/README.txt | 194 -------------------------------------- 1 file changed, 194 deletions(-) delete mode 100644 lib/Target/X86/README.txt diff --git a/lib/Target/X86/README.txt b/lib/Target/X86/README.txt deleted file mode 100644 index 558846d6023..00000000000 --- a/lib/Target/X86/README.txt +++ /dev/null @@ -1,194 +0,0 @@ -//===- README.txt - Information about the X86 backend and related files ---===// -// -// This file contains random notes and points of interest about the X86 backend. -// -//===----------------------------------------------------------------------===// - -=========== -I. Overview -=========== - -This directory contains a machine description for the X86 processor family. -Currently this machine description is used for a high performance code generator -used by the LLVM JIT and static code generators. One of the main objectives -that we would like to support with this project is to build a nice clean code -generator that may be extended in the future in a variety of ways: new targets, -new optimizations, new transformations, etc. - -This document describes the current state of the X86 code generator, along with -implementation notes, design decisions, and other stuff. - - -=================================== -II. Architecture / Design Decisions -=================================== - -We designed the infrastructure into the generic LLVM machine specific -representation, which allows us to support as many targets as possible with our -framework. This framework should allow us to share many common machine specific -transformations (register allocation, instruction scheduling, etc...) among all -of the backends that may eventually be supported by LLVM, and ensures that the -JIT and static compiler backends are largely shared. - -At the high-level, LLVM code is translated to a machine specific representation -formed out of MachineFunction, MachineBasicBlock, and MachineInstr instances -(defined in include/llvm/CodeGen). This representation is completely target -agnostic, representing instructions in their most abstract form: an opcode and a -series of operands. This representation is designed to support both SSA -representation for machine code, as well as a register allocated, non-SSA form. - -Because the Machine* representation must work regardless of the target machine, -it contains very little semantic information about the program. To get semantic -information about the program, a layer of Target description datastructures are -used, defined in include/llvm/Target. - -Note that there is some amount of complexity that the X86 backend contains due -to the Sparc backend's legacy requirements. These should eventually fade away -as the project progresses. - - -SSA Instruction Representation ------------------------------- -Target machine instructions are represented as instances of MachineInstr, and -all specific machine instruction types should have an entry in the -X86InstrInfo.td file. In the X86 backend, there are two particularly -interesting forms of machine instruction: those that produce a value (such as -add), and those that do not (such as a store). - -Instructions that produce a value use Operand #0 as the "destination" register. -When printing the assembly code with the built-in machine instruction printer, -these destination registers will be printed to the left side of an '=' sign, as -in: %reg1027 = add %reg1026, %reg1025 - -This `add' MachineInstruction contains three "operands": the first is the -destination register (#1027), the second is the first source register (#1026) -and the third is the second source register (#1025). Never forget the -destination register will show up in the MachineInstr operands vector. The code -to generate this instruction looks like this: - - BuildMI(BB, X86::ADD32rr, 2, 1027).addReg(1026).addReg(1025); - -The first argument to BuildMI is the basic block to append the machine -instruction to, the second is the opcode, the third is the number of operands, -the fourth is the destination register. The two addReg calls specify operands -in order. - -MachineInstrs that do not produce a value do not have this implicit first -operand, they simply have #operands = #uses. To create them, simply do not -specify a destination register to the BuildMI call. - - -====================== -IV. Source Code Layout -====================== - -The LLVM code generator is composed of source files primarily in the following -locations: - -include/llvm/CodeGen --------------------- -This directory contains header files that are used to represent the program in a -machine specific representation. It currently also contains a bunch of stuff -used by the Sparc backend that we don't want to get mixed up in, such as -register allocation internals. - -include/llvm/Target -------------------- -This directory contains header files that are used to interpret the machine -specific representation of the program. This allows us to write generic -transformations that will work on any target that implements the interfaces -defined in this directory. The only classes used by the X86 backend so far are -the TargetMachine, TargetData, MachineInstrInfo, and MRegisterInfo classes. - -lib/CodeGen ------------ -This directory will contain all of the target independent transformations (for -example, register allocation) that we write. These transformations should only -use information exposed through the Target interface, they should not include -any target specific header files. - -lib/Target/X86 --------------- -This directory contains the machine description for X86 that is required to the -rest of the compiler working. It contains any code that is truly specific to -the X86 backend, for example the instruction selector and machine code emitter. - -lib/ExecutionEngine/JIT ------------------------ -This directory contains the top-level code for the JIT compiler. This code -basically boils down to a call to TargetMachine::addPassesToJITCompile, and -handles the compile-dispatch-recompile cycle. - -test/Regression/CodeGen/X86 ---------------------------- -This directory contains regression tests for the X86 code generator. - - -================================================== -V. Strange Things, or, Things That Should Be Known -================================================== - -Representing memory in MachineInstrs ------------------------------------- - -The x86 has a very, uhm, flexible, way of accessing memory. It is capable of -forming memory addresses of the following expression directly in integer -instructions (which use ModR/M addressing): - - Base+[1,2,4,8]*IndexReg+Disp32 - -Wow, that's crazy. In order to represent this, LLVM tracks no less that 4 -operands for each memory operand of this form. This means that the "load" form -of 'mov' has the following "Operands" in this order: - -Index: 0 | 1 2 3 4 -Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement -OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm - -Stores and all other instructions treat the four memory operands in the same -way, in the same order. - - -====================== -VI. Instruction naming -====================== - -An instruction name consists of the base name, a default operand size -followed by a character per operand with an optional special size. For -example: - -ADD8rr -> add, 8-bit register, 8-bit register - -IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate - -IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate - -MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory - - -========================== -VII. TODO / Future Projects -========================== - -Ideas for Improvements: ------------------------ -1. Implement an *optimal* linear time instruction selector -2. Implement lots of nifty runtime optimizations -3. Implement new targets: IA64? X86-64? M68k? MMIX? Who knows... - -Infrastructure Improvements: ----------------------------- - -1. X86/Printer.cpp and Sparc/EmitAssembly.cpp both have copies of what is - roughly the same code, used to output constants in a form the assembler - can understand. These functions should be shared at some point. They - should be rewritten to pass around iostreams instead of strings. The - list of functions is as follows: - - isStringCompatible - toOctal - ConstantExprToString - valToExprString - getAsCString - printSingleConstantValue (with TypeToDataDirective inlined) - printConstantValueOnly