Akira Hatanaka
2010-Sep-07 17:48 UTC
[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>
Bill Wendling
2010-Sep-07 20:31 UTC
[LLVMdev] MachineMemOperand and dependence information
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
Akira Hatanaka
2010-Sep-07 22:54 UTC
[LLVMdev] MachineMemOperand and dependence information
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>
Akira Hatanaka
2010-Sep-07 23:07 UTC
[LLVMdev] MachineMemOperand and dependence information
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>