[LLVMdev] MachineMemOperand and dependence information

Akira Hatanaka ahatanak at gmail.com
Tue Sep 7 10:48:46 PDT 2010


 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>


More information about the llvm-dev mailing list