[LLVMdev] MachineMemOperand and dependence information
Bill Wendling
wendling at apple.com
Tue Sep 7 16:38:14 PDT 2010
Ah! Okay. So it's not the generic code. Yes, it's probably a bug that the memoperands aren't propagated to the new instruction. Please file a bug report with a small testcase.
-bw
On Sep 7, 2010, at 4:07 PM, Akira Hatanaka wrote:
> Sorry, this is the part in ARMLoadStoreOptimizer.cpp that creates a LDRD instruction.
>
> Ops.pop_back();
> Ops.pop_back();
>
> // Form the pair instruction.
> if (isLd) {
> MachineInstrBuilder MIB = BuildMI(*MBB, InsertPos,
> dl, TII->get(NewOpc))
> .addReg(EvenReg, RegState::Define)
> .addReg(OddReg, RegState::Define)
> .addReg(BaseReg);
> if (!isT2)
> MIB.addReg(OffReg);
> MIB.addImm(Offset).addImm(Pred).addReg(PredReg);
> ++NumLDRDFormed;
>
>
> On Tue, Sep 7, 2010 at 1:31 PM, Bill Wendling <wendling at apple.com> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100907/061b63cc/attachment.html>
More information about the llvm-dev
mailing list