This file is obsolete

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14005 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 0 insertions, 194 deletions

diff --git a/lib/Target/X86/README.txt b/lib/Target/X86/README.txt
deleted file mode 100644
index 558846d..0000000
--- 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