[LLVMdev] MachineMemOperand and dependence information

[Akira Hatanaka]

Thank you for replying to my email.

I am not sure if I understand your point, but are you suggesting this is
done during instruction selection? It seems that this transformation takes
place inside ARMPreAllocLoadStoreOpt:::RescheduleOps (after line 1501).
http://llvm.org/doxygen/ARMLoadStoreOptimizer_8cpp_source.html.

01504           Ops.pop_back
<http://llvm.org/doxygen/classllvm_1_1SmallVectorImpl.html#aad4bda81394ccf6cb87db6d2ae881a11>();
01505           Ops.pop_back
<http://llvm.org/doxygen/classllvm_1_1SmallVectorImpl.html#aad4bda81394ccf6cb87db6d2ae881a11>();
01506
01507           // Form the pair instruction.
01508           if (isLd) {
01509             MachineInstrBuilder
<http://llvm.org/doxygen/classllvm_1_1MachineInstrBuilder.html> MIB =
BuildMI <http://llvm.org/doxygen/namespacellvm.html#a7145156f8301eacb56ec8307c140542a>(*MBB,
InsertPos,
01510                                               dl, TII->get(NewOpc))
01511               .addReg(EvenReg, RegState::Define
<http://llvm.org/doxygen/namespacellvm_1_1RegState.html#aee618dbf47179807cf5c50c1f795be51a72c17e2ff2d5af62a30e56ac152aa8d5>)
01512               .addReg
<http://llvm.org/doxygen/classllvm_1_1MachineInstrBuilder.html#a5125cce72b214df09ca8f93dcbbf4c3a>(OddReg,
RegState::Define
<http://llvm.org/doxygen/namespacellvm_1_1RegState.html#aee618dbf47179807cf5c50c1f795be51a72c17e2ff2d5af62a30e56ac152aa8d5>)
01513               .addReg
<http://llvm.org/doxygen/classllvm_1_1MachineInstrBuilder.html#a5125cce72b214df09ca8f93dcbbf4c3a>(BaseReg);
01514             if (!isT2)
01515               MIB.addReg
<http://llvm.org/doxygen/classllvm_1_1MachineInstrBuilder.html#a5125cce72b214df09ca8f93dcbbf4c3a>(OffReg);
01516             MIB.addImm
<http://llvm.org/doxygen/classllvm_1_1MachineInstrBuilder.html#a9f1fae6a5dbb6e378ca85df1fded8515>(Offset).addImm
<http://llvm.org/doxygen/classllvm_1_1MachineInstrBuilder.html#a9f1fae6a5dbb6e378ca85df1fded8515>(Pred).addReg
<http://llvm.org/doxygen/classllvm_1_1MachineInstrBuilder.html#a5125cce72b214df09ca8f93dcbbf4c3a>(PredReg);
01517             ++NumLDRDFormed;


I just wanted to know whether or not the MachineMemOperands were
intentionally left out and if it is okay to add the MachineMemOperands to
the newly created instruction (would it break anything?).

Thank you.

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/b0ae7766/attachment.html>