remove two docs about the old Sparc backend which used Value*'s for vregs.

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

2 files changed, 0 insertions, 76 deletions

diff --git a/docs/HistoricalNotes/2001-07-08-InstructionSelection.txt b/docs/HistoricalNotes/2001-07-08-InstructionSelection.txt
deleted file mode 100644
index 8cc75b89b8..0000000000
--- a/docs/HistoricalNotes/2001-07-08-InstructionSelection.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-Date: Sun, 8 Jul 2001 09:37:22 -0500
-From: Vikram S. Adve <vadve@cs.uiuc.edu>
-To: Ruchira Sasanka <sasanka@students.uiuc.edu>
-Cc: Chris Lattner <lattner@cs.uiuc.edu>
-Subject: machine instruction operands
-
-Ruchira,
-
-When generating machine instructions, I have to make several choices about
-operands.  For cases were a register is required, there are 3 cases:
-
-1. The register is for a Value* that is already in the VM code.
-
-2. The register is for a value that is not in the VM code, usually because 2
-machine instructions get generated for a single VM instruction (and the
-register holds the result of the first m/c instruction and is used by the
-second m/c instruction).
-
-3. The register is a pre-determined machine register.
-
-E.g, for this VM instruction:
-        ptr = alloca type, numElements
-I have to generate 2 machine instructions:
-        reg = mul constant, numElements
-        ptr = add %sp, reg
-
-Each machine instruction is of class MachineInstr.
-It has a vector of operands.  All register operands have type MO_REGISTER.
-The 3 types of register operands are marked using this enum:
-
- enum VirtualRegisterType {
-    MO_VMVirtualReg,            // virtual register for *value
-    MO_MInstrVirtualReg,        // virtual register for result of *minstr
-    MO_MachineReg               // pre-assigned machine register `regNum'
-  } vregType;
-
-Here's how this affects register allocation:
-
-1. MO_VMVirtualReg is the standard case: you just do the register
-allocation.
-
-2. MO_MInstrVirtualReg is the case where there is a hidden register being
-used.  You should decide how you want to handle it, e.g., do you want do
-create a Value object during the preprocessing phase to make the value
-explicit (like for address register for the RETURN instruction).
-
-3. For case MO_MachineReg, you don't need to do anything, at least for
-SPARC. The only machine regs I am using so far are %g0 and %sp.
-
---Vikram
-
diff --git a/docs/HistoricalNotes/2001-07-08-InstructionSelection2.txt b/docs/HistoricalNotes/2001-07-08-InstructionSelection2.txt
deleted file mode 100644
index 1ae006d508..0000000000
--- a/docs/HistoricalNotes/2001-07-08-InstructionSelection2.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Date: Sun, 8 Jul 2001 10:02:20 -0500
-From: Vikram S. Adve <vadve@cs.uiuc.edu>
-To: vadve@cs.uiuc.edu, Ruchira Sasanka <sasanka@students.uiuc.edu>
-Cc: Chris Lattner <lattner@cs.uiuc.edu>
-Subject: RE: machine instruction operands
-
-I got interrupted and forgot to explain the example.  In that case:
-
-        reg will be the 3rd operand of MUL and it will be of type
-MO_MInstrVirtualReg.  The field MachineInstr* minstr will point to the
-instruction that computes reg.
-
-        numElements will be an immediate constant, not a register.
-
-        %sp will be operand 1 of ADD and it will be of type MO_MachineReg.  The
-field regNum identifies the register.
-
-        numElements will be operand 2 of ADD and it will be of type
-MO_VMVirtualReg.  The field Value* value identifies the value.
-
-        ptr will be operand 3 of ADD will also be %sp, i.e., of
-        type MO_MachineReg. regNum identifies the register.
-
---Vikram
-