llvm dev - Oct 2012 - [LLVMdev] Meaning of the nocapture attribute (possible bug?)

Regarding the nocapture attribute the language ref says: "the callee 
does not make any copies of the pointer that outlive the callee itself".
>From I inferred that it is OK for the callee to make a copy of the 
pointer that doesn't outlive the call. However if I write some code that 
does this the optimizers don't do what I'd expect. Consider the 
following the example:

declare void @g(i32** %p, i32* %q) nounwind

define i32 @f(i32* noalias nocapture %p) nounwind {
entry:
   %q = alloca i32*
   call void @g(i32** %q, i32* %p) nounwind
   store i32 0, i32* %p
   %0 = load i32** %q
   store i32 1, i32* %0
   %1 = load i32* %p
   ret i32 %1
}

I would expect it to be valid for g() to store the value of its second 
argument to the object pointed to by its first argument. Because of this 
I would expect a possible memory dependency between the last load (%1 = 
load i32* %p) and the last store (store i32 1, i32* %0). However if I 
run the example through opt -basicaa -gvn then the return instruction is 
optimized to ret i32 0 suggesting basicaa doesn't think there is any 
such dependency.

Is this a bug in the basic alias analysis pass or am I misunderstanding 
the semantics of nocapture?

-- 
Richard Osborne | XMOS
http://www.xmos.com

Hi Richard, I think it is a bug.

Ciao, Duncan.

On 08/10/12 14:34, Richard Osborne wrote:
> Regarding the nocapture attribute the language ref says: "the callee
does not
> make any copies of the pointer that outlive the callee itself". From I
inferred
> that it is OK for the callee to make a copy of the pointer that doesn't
outlive
> the call. However if I write some code that does this the optimizers
don't do
> what I'd expect. Consider the following the example:
>
> declare void @g(i32** %p, i32* %q) nounwind
>
> define i32 @f(i32* noalias nocapture %p) nounwind {
> entry:
>    %q = alloca i32*
>    call void @g(i32** %q, i32* %p) nounwind
>    store i32 0, i32* %p
>    %0 = load i32** %q
>    store i32 1, i32* %0
>    %1 = load i32* %p
>    ret i32 %1
> }
>
> I would expect it to be valid for g() to store the value of its second
argument
> to the object pointed to by its first argument. Because of this I would
expect a
> possible memory dependency between the last load (%1 = load i32* %p) and
the
> last store (store i32 1, i32* %0). However if I run the example through opt
> -basicaa -gvn then the return instruction is optimized to ret i32 0
suggesting
> basicaa doesn't think there is any such dependency.
>
> Is this a bug in the basic alias analysis pass or am I misunderstanding the
> semantics of nocapture?
>

Thanks for your reply, I've filed this as PR14045:

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

On 08/10/12 14:54, Duncan Sands wrote:
> Hi Richard, I think it is a bug.
>
> Ciao, Duncan.
>
> On 08/10/12 14:34, Richard Osborne wrote:
>> Regarding the nocapture attribute the language ref says: "the
callee
>> does not
>> make any copies of the pointer that outlive the callee itself".
From
>> I inferred
>> that it is OK for the callee to make a copy of the pointer that 
>> doesn't outlive
>> the call. However if I write some code that does this the optimizers 
>> don't do
>> what I'd expect. Consider the following the example:
>>
>> declare void @g(i32** %p, i32* %q) nounwind
>>
>> define i32 @f(i32* noalias nocapture %p) nounwind {
>> entry:
>>    %q = alloca i32*
>>    call void @g(i32** %q, i32* %p) nounwind
>>    store i32 0, i32* %p
>>    %0 = load i32** %q
>>    store i32 1, i32* %0
>>    %1 = load i32* %p
>>    ret i32 %1
>> }
>>
>> I would expect it to be valid for g() to store the value of its 
>> second argument
>> to the object pointed to by its first argument. Because of this I 
>> would expect a
>> possible memory dependency between the last load (%1 = load i32* %p) 
>> and the
>> last store (store i32 1, i32* %0). However if I run the example 
>> through opt
>> -basicaa -gvn then the return instruction is optimized to ret i32 0 
>> suggesting
>> basicaa doesn't think there is any such dependency.
>>
>> Is this a bug in the basic alias analysis pass or am I 
>> misunderstanding the
>> semantics of nocapture?
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Richard Osborne | XMOS
http://www.xmos.com

Is this code valid?

Function f takes a "nocapture" pointer p, and passes it to function g 
that does not have nocapture in its parameter list.  There is nothing to 
stop g from "capturing" p.

-Krzysztof


On 10/8/2012 8:54 AM, Duncan Sands wrote:
> Hi Richard, I think it is a bug.
>
> Ciao, Duncan.
>
> On 08/10/12 14:34, Richard Osborne wrote:
>> Regarding the nocapture attribute the language ref says: "the
callee
>> does not
>> make any copies of the pointer that outlive the callee itself".
From I
>> inferred
>> that it is OK for the callee to make a copy of the pointer that
>> doesn't outlive
>> the call. However if I write some code that does this the optimizers
>> don't do
>> what I'd expect. Consider the following the example:
>>
>> declare void @g(i32** %p, i32* %q) nounwind
>>
>> define i32 @f(i32* noalias nocapture %p) nounwind {
>> entry:
>>    %q = alloca i32*
>>    call void @g(i32** %q, i32* %p) nounwind
>>    store i32 0, i32* %p
>>    %0 = load i32** %q
>>    store i32 1, i32* %0
>>    %1 = load i32* %p
>>    ret i32 %1
>> }
>>
>> I would expect it to be valid for g() to store the value of its second
>> argument
>> to the object pointed to by its first argument. Because of this I
>> would expect a
>> possible memory dependency between the last load (%1 = load i32* %p)
>> and the
>> last store (store i32 1, i32* %0). However if I run the example
>> through opt
>> -basicaa -gvn then the return instruction is optimized to ret i32 0
>> suggesting
>> basicaa doesn't think there is any such dependency.
>>
>> Is this a bug in the basic alias analysis pass or am I
>> misunderstanding the
>> semantics of nocapture?
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation