How to implement MyArchInstrInfo::isLoadFromStackSlot where most instructions have an Offset.

In order to handle register allocation of more complex functions, I have to implement the others methods from the MyArchInstrInfo.cpp.

The first one is the isLoadFromStack, that return the frameIndex referenced by the Machine Instruction.

I took a look at the implementation of this function in many others architectures. It’s always a switch/case on a few instructions of the architecture, followed by some access to the properties of the instruction parameters.

With my architecture, most of the selected instruction (MOV but also arithmetic instructions) will load one or even worst two operands from a Stack Slot: the Offset and Offset/Offset addressing mode.

/// isLoadFromStackSlot - If the specified machine instruction is a direct

/// load from a stack slot, return the virtual or physical register number of

/// the destination along with the FrameIndex of the loaded stack slot. If

/// not, return 0. This predicate must return 0 if the instruction has

/// any side effects other than loading from the stack slot.

unsigned CLPInstrInfo::isLoadFromStackSlot(const MachineInstr *MI,

int &FrameIndex) const {

What is the purpose this method? Finding the highest position already allocated in the Stack?

In that case, for Offset/Offset addressing mode, I will have to return the highest offset.

As for other architecture, I can implement a switch/case, but it will be very large. Most of the instructions have an Offset/Offset addressing mode.

Do I have to implement this methods only for the MOV instructions or also for the arithmetic instructions fetching operands from Stack?

Is there a way to add a property to tag ‘LoadFromStackSlot’ instructions or instruction classes at the level of MyArchInstrInfo.td or MyArchInstrDef.td file?

Any suggestions suggestion are welcome…

TIA, Dominique Torette

In order to handle register allocation of more complex functions, I have to implement the others methods from the MyArchInstrInfo.cpp.
The first one is the isLoadFromStack, that return the frameIndex referenced by the Machine Instruction.
I took a look at the implementation of this function in many others architectures. It’s always a switch/case on a few instructions of the architecture, followed by some access to the properties of the instruction parameters.
With my architecture, most of the selected instruction (MOV but also arithmetic instructions) will load one or even worst two operands from a Stack Slot: the Offset and Offset/Offset addressing mode.

/// isLoadFromStackSlot - If the specified machine instruction is a direct
/// load from a stack slot, return the virtual or physical register number of
/// the destination along with the FrameIndex of the loaded stack slot. If
/// not, return 0. This predicate must return 0 if the instruction has
/// any side effects other than loading from the stack slot.
unsigned CLPInstrInfo::isLoadFromStackSlot(const MachineInstr *MI,
                        int &FrameIndex) const {

What is the purpose this method? Finding the highest position already allocated in the Stack?

This callback doesn't seem to be used too much. In general it is a good idea to look for the users of a callback to get a feeling for how much/where it is used.
This one in particular seems rarely used:
- Some code uses it to identify "reload" instructions to create statistics and comments in the assembly output. (This doesn't seem to be perfect as for example I don't see it catching the cases where the reload was folded into arithmetic instruction on x86).
- StackSlotColoring uses it to remove some store/load sequences if easily possible.
- InlineSpiller/MachineLICM appear to have some rules to enable some optimisations for reloads (identifying certain safe code patterns).

So this all seems to only be involved in pretty minor optimizations. The code in MachineLICM looks to me like it assumes only one FrameIndex is touched, so you may be better off not reporting anything if you have two loads folded in a single instruction. (Short of improving/fixing the usage there).

- Matthias