[llvm-dev] How to handle ISD::STORE when both operands are FrameIndex?

[Krzysztof Parzyszek via llvm-dev]

On Wed, 26 Jun 2019 at 10:27, Gleb Popov <mailto:6yearold at gmail.com> wrote:
>
> Silly me -_\
> Why was I talking about a load all this time? You're right, I needed a simple mov there. I have added the following code into MyBackendDAGToDAGISel::Select() and it worked:
>
> if(FrameIndexSDNode *FIN = dyn_cast<FrameIndexSDNode>(N))
>   {
>       auto Addr = CurDAG->getTargetFrameIndex(
>                     FIN->getIndex(), TLI->getPointerTy(CurDAG->getDataLayout()));
>       SDNode *MOV = CurDAG->getMachineNode(MYBACK::MovRI, dl, MVT::i32, Addr);
>       CurDAG->ReplaceAllUsesWith(N, MOV);
>       return;
>   }

Eventually you will need to replace the frame index with actual code that calculates the address based on the stack pointer/frame pointer.  This is done via a target hook TargetRegisterInfo::eliminateFrameIndex.  It takes the instruction with the FI to be replaced, and the operand number that contains the FI:

  virtual void eliminateFrameIndex(MachineBasicBlock::iterator MI,
                                   int SPAdj, unsigned FIOperandNum,
                                   RegScavenger *RS = nullptr) const = 0;

It makes the replacement a lot easier to have the frame index always in a context where it's added to an immediate, for example a load from fi#0 may use it in a place of a base register, followed by an immediate offset operand.  During the FI elimination, when you know that fi#0 is SP+32, you put SP in the base register operand and add the 32 to the offset field.  In the same way it's convenient to have the transfer of a FI into a register be an add-immediate of 0, so instead of "mov reg, fi#0" you'd have "addi reg, fi#0, 0".  Now the replacement can simply replace the operands with "SP" and "32" respectively (for the case of fi#0 being SP+32), i.e. you'd end up with "addi reg, SP, 32".  When you have a simple "mov reg, fi#0", the replacement will be harder, since you can't have "mov reg, SP+32".

-- 
Krzysztof Parzyszek  mailto:kparzysz at quicinc.com   LLVM compiler development