mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-18 18:42:46 +02:00
Add notes on instruction selection pass
llvm-svn: 193
This commit is contained in:
parent
897bdcb525
commit
ec521ed1f5
51
docs/HistoricalNotes/2001-07-08-InstructionSelection.txt
Normal file
51
docs/HistoricalNotes/2001-07-08-InstructionSelection.txt
Normal file
@ -0,0 +1,51 @@
|
|||||||
|
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
|
||||||
|
|
25
docs/HistoricalNotes/2001-07-08-InstructionSelection2.txt
Normal file
25
docs/HistoricalNotes/2001-07-08-InstructionSelection2.txt
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
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
|
||||||
|
|
Loading…
Reference in New Issue
Block a user