[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