[LLVMbugs] [Bug 8113] New: MachineMemOperands not propageted in ARMLoadStoreOptimizer.cpp

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=8113

           Summary: MachineMemOperands not propageted in
                    ARMLoadStoreOptimizer.cpp
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ahatanak at gmail.com
                CC: llvmbugs at cs.uiuc.edu


A potential bug in ARMLoadStoreOptimizer.cpp related to the questions asked in
the following link (It doesn't seem to result in generation of incorrect code,
but I am not sure whether it is correct not to propagate MachineMemOperands).
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-September/034485.html

Here are the sample source file and .ll file I used.
- input source file
void f(int *a, int* b, int n) {
  int i = 0;

  for (i = 0; i < n - 1; ++i)
    b[i] = a[i] + a[i + 1];
}

- bc file, generated by entering
# llvm-gcc -emit-llvm -O3 -c f.c -o f.bc -m32 

; ModuleID = '<stdin>'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i386-unknown-linux-gnu"

define void @f(i32* nocapture %a, i32* nocapture %b, i32 %n) nounwind {
entry:
  %0 = add nsw i32 %n, -1                         ; <i32> [#uses=2]
  %1 = icmp sgt i32 %0, 0                         ; <i1> [#uses=1]
  br i1 %1, label %bb, label %return

bb:                                               ; preds = %bb, %entry
  %i.03 = phi i32 [ %tmp, %bb ], [ 0, %entry ]    ; <i32> [#uses=3]
  %scevgep = getelementptr i32* %a, i32 %i.03     ; <i32*> [#uses=1]
  %scevgep4 = getelementptr i32* %b, i32 %i.03    ; <i32*> [#uses=1]
  %tmp = add i32 %i.03, 1                         ; <i32> [#uses=3]
  %scevgep5 = getelementptr i32* %a, i32 %tmp     ; <i32*> [#uses=1]
  %2 = load i32* %scevgep, align 4                ; <i32> [#uses=1]
  %3 = load i32* %scevgep5, align 4               ; <i32> [#uses=1]
  %4 = add nsw i32 %3, %2                         ; <i32> [#uses=1]
  store i32 %4, i32* %scevgep4, align 4
  %exitcond = icmp eq i32 %tmp, %0                ; <i1> [#uses=1]
  br i1 %exitcond, label %return, label %bb

return:                                           ; preds = %bb, %entry
  ret void
}

# gdb llc
(gdb) b ARMLoadStoreOptimizer.cpp:1504
(gdb) r -march=arm -mcpu=cortex-a8 f.bc -o f.arm.s
(gdb) p MF->dump()
...
BB#2: derived from LLVM BB %bb
    Predecessors according to CFG: BB#1 BB#2
        %reg16389<def> = PHI %reg16385, <BB#1>, %reg16394, <BB#2>;
GPR:%reg16389,16385,16394
        %reg16390<def> = PHI %reg16388, <BB#1>, %reg16393, <BB#2>;
GPR:%reg16390,16388,16393
        %reg16391<def> = PHI %reg16387, <BB#1>, %reg16392, <BB#2>;
GPR:%reg16391,16387,16392
        %reg16399<def> = LDR %reg16390, %reg0, 4100, pred:14, pred:%reg0;
mem:LD4[%scevgep9] GPR:%reg16399,16390
        %reg16400<def> = LDR %reg16390, %reg0, 0, pred:14, pred:%reg0;
mem:LD4[%lsr.iv3] GPR:%reg16400,16390
...
(gdb) fin
(gdb) p MF->dump()
...
BB#2: derived from LLVM BB %bb
    Predecessors according to CFG: BB#1 BB#2
        %reg16389<def> = PHI %reg16385, <BB#1>, %reg16394, <BB#2>;
GPR:%reg16389,16385,16394
        %reg16390<def> = PHI %reg16388, <BB#1>, %reg16393, <BB#2>;
GPR:%reg16390,16388,16393
        %reg16391<def> = PHI %reg16387, <BB#1>, %reg16392, <BB#2>;
GPR:%reg16391,16387,16392
        %reg16399<def>, %reg16400<def> = LDRD %reg16390, %reg0, 260, pred:14,
pred:%reg0; GPR:%reg16399,16400,16390
...

When the two LDR instructions are removed from the BB and a new LDRD
instruction is added, the MachineMemOperands attached to the LDR instructions
(mem:LD4[%scevgep9] and mem:LD4[%lsr.iv3]) do not get propagated.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.