[LLVMbugs] [Bug 19842] New: Functionattrs incorrectly marks argument as readnone
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri May 23 09:10:17 PDT 2014
http://llvm.org/bugs/show_bug.cgi?id=19842
Bug ID: 19842
Summary: Functionattrs incorrectly marks argument as readnone
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: rob.lougher.llvm at gmail.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Running the following IR through opt -functionattrs will incorrectly mark
%store's %p as readnone. The bug is due to incorrectly handling the copy of
the pointer made by @get_pntr, because @get_pntr itself is marked readnone.
define i32* @get_pntr(i32* %p) nounwind uwtable {
entry:
ret i32* %p
}
define void @store(i32* %p) noinline nounwind uwtable {
entry:
%call = call i32* @get_pntr(i32* %p)
store i32 10, i32* %call, align 4
ret void
}
This can be seen with the following C testcase. The bug leads to GVN
incorrectly removing the return load:
======== test.c ===========
int *get_pntr(int *p) {
return p;
}
__attribute__((noinline))
void store(int *p) {
int *p2 = get_pntr(p);
*p2 = 10;
}
int test() {
int i;
store(&i);
return i;
}
-----------------------------
Compile in two steps as follows:
clang -O1 -emit-llvm test.c -c -o test.bc
opt -basicaa -inline -functionattrs -gvn -S test.bc
We get the following IR:
--------------------------------------------------
define i32* @get_pntr(i32* readnone %p) {
entry:
ret i32* %p
}
define void @store(i32* nocapture readnone %p) {
entry:
store i32 10, i32* %p, align 4, !tbaa !1
ret void
}
define i32 @test() {
entry:
%i = alloca i32, align 4
call void @store(i32* %i)
ret i32 undef
}
--------------------------------------------------
GVN removes the load because it believes that the call to %store has no affect
on %i, and as %i has just been allocated, the loaded value is undefined.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140523/d9cc2baa/attachment.html>
More information about the llvm-bugs
mailing list