Displaying 4 results from an estimated 4 matches for "get_pntr".
Did you mean:
get_entry
2014 May 23
2
[LLVMdev] GVN incorrectly handling readnone parameter attribute?
...ug filed:
> http://llvm.org/bugs/show_bug.cgi?id=19842
Thank you!
Strangely enough, my first conclusion was that %p was being marked
> readnone incorrectly as it wasn't handling the copy via @get_addr.
>
Sorry -- saying %p alone is ambiguous because there's the %p parameter
of @get_pntr
and the %p parameter of @store. It is correct to mark %p readnone in
@get_pntr. From function entrance to exit, it does not write to the pointer
passed in. It is incorrect to mark %p readnone in @store, as it receives a
pointer then writes to it. Supposing the @get_pntr loaded a pointer from
some g...
2014 May 23
2
[LLVMdev] GVN incorrectly handling readnone parameter attribute?
Confirmed, this is a bug. This
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
}
run through opt -functionattrs gets a 'readnone' on @store's %p. That's
wrong, i...
2014 May 21
4
[LLVMdev] GVN incorrectly handling readnone parameter attribute?
Hi,
I'm investigating a bug which I have so far been able to narrow down
to the following small testcase:
======== 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;
}
-----------------------------
If this is compiled in two steps as follows:
clang -O1 -emit-llvm test.c -c -o test.bc
opt...
2014 May 22
2
[LLVMdev] GVN incorrectly handling readnone parameter attribute?
On 05/21/2014 02:52 PM, Robert Lougher wrote:
> On 21 May 2014 21:40, Robert Lougher <rob.lougher at gmail.com> wrote:
>> 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
>> }
>>
> Further to my first post, based on the definit...