llvm dev - Sep 2010 - [LLVMdev] MachineMemOperand and dependence information

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]

Q2) If a pass generates new instructions and it is not possible to add
MachineMemOperands in a way that correctly reflects dependence information,
should the MachineMemOperands be removed altogether? The pass I am writing
does something similar to loop unrolling and replicates and reorders
existing instructions.

For example, a single load instruction could be replicated three times.
(before transformation)
%reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0;
mem:LD4[%uglygep10]

(after transformation)
%reg1043<def> = LDR %reg1040, %reg0, 4100, pred:14, pred:%reg0;
mem:LD4[%uglygep10]
...
%reg1053<def> = LDR %reg1050, %reg0, 4100, pred:14, pred:%reg0;
mem:LD4[%uglygep10]
...
%reg1063<def> = LDR %reg1060, %reg0, 4100, pred:14, pred:%reg0;
mem:LD4[%uglygep10]

In this example, should mem:LD4[%uglygep10] be removed from the three
instructions so that passes run later will not use dependence information
that is no longer correct?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100907/39563936/attachment.html>

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

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>

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