1 Date: Sun, 8 Jul 2001 09:37:22 -0500
2 From: Vikram S. Adve <vadve@cs.uiuc.edu>
3 To: Ruchira Sasanka <sasanka@students.uiuc.edu>
4 Cc: Chris Lattner <lattner@cs.uiuc.edu>
5 Subject: machine instruction operands
9 When generating machine instructions, I have to make several choices about
10 operands. For cases were a register is required, there are 3 cases:
12 1. The register is for a Value* that is already in the VM code.
14 2. The register is for a value that is not in the VM code, usually because 2
15 machine instructions get generated for a single VM instruction (and the
16 register holds the result of the first m/c instruction and is used by the
17 second m/c instruction).
19 3. The register is a pre-determined machine register.
21 E.g, for this VM instruction:
22 ptr = alloca type, numElements
23 I have to generate 2 machine instructions:
24 reg = mul constant, numElements
27 Each machine instruction is of class MachineInstr.
28 It has a vector of operands. All register operands have type MO_REGISTER.
29 The 3 types of register operands are marked using this enum:
31 enum VirtualRegisterType {
32 MO_VMVirtualReg, // virtual register for *value
33 MO_MInstrVirtualReg, // virtual register for result of *minstr
34 MO_MachineReg // pre-assigned machine register `regNum'
37 Here's how this affects register allocation:
39 1. MO_VMVirtualReg is the standard case: you just do the register
42 2. MO_MInstrVirtualReg is the case where there is a hidden register being
43 used. You should decide how you want to handle it, e.g., do you want do
44 create a Value object during the preprocessing phase to make the value
45 explicit (like for address register for the RETURN instruction).
47 3. For case MO_MachineReg, you don't need to do anything, at least for
48 SPARC. The only machine regs I am using so far are %g0 and %sp.