[LLVMdev] MachineMemOperand and dependence information

[Bill Wendling]

On Sep 7, 2010, at 10:48 AM, Akira Hatanaka wrote:

> I have two questions regarding MachineMemOperands and dependence information.
> 
> Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps.
> 
> (before optimization)
> %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10]
> %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14, pred:%reg0; mem:LD4[%uglygep2021]
> 
> (after optimization)
> %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, pred:%reg0
> 
> Are there any reasons they need to be removed?
> Would it break something if both MachineMemOperands were added to the newly generated instruction? 
> 
> (after optimization)
> %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, pred:%reg0; mem:LD4[%uglygep10], mem:LD4[%uglygep2021]

If I had to guess, I would think it's because of how LDR is defined:

def addrmodepc : Operand<i32>,
                 ComplexPattern<i32, 2, "SelectAddrModePC", []> {
  let PrintMethod = "printAddrModePCOperand";
  let MIOperandInfo = (ops GPR, i32imm);
}
def LDR  : AI2ldw<(outs GPR:$dst), (ins addrmode2:$addr), LdFrm, IIC_iLoadr,
               "ldr", "\t$dst, $addr",
               [(set GPR:$dst, (load addrmode2:$addr))]>;

It's using addrmodepc, which is a ComplexPattern. The TableGen code cannot handle resetting the memoperands if it's dealing with a ComplexPattern. There's a similar bug in the X86 target.

-bw