[LLVMbugs] [Bug 8113] New: MachineMemOperands not propageted in ARMLoadStoreOptimizer.cpp
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Wed Sep 8 10:28:01 PDT 2010
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.
More information about the llvm-bugs
mailing list