<div dir="ltr"><div>Confirmed, this is a bug. This</div><div><br></div><div>define i32* @get_pntr(i32* %p) nounwind uwtable {</div><div>entry:</div><div>  ret i32* %p</div><div>}</div><div>define void @store(i32* %p) noinline nounwind uwtable {<br>

</div><div>entry:</div><div>  %call = call i32* @get_pntr(i32* %p)</div><div>  store i32 10, i32* %call, align 4</div><div>  ret void</div><div>}</div><div><br></div><div>run through opt -functionattrs gets a 'readnone' on @store's %p. That's wrong, it clearly stores to it. The bug is due to incorrectly handling the copy of the pointer made by @get_pntr, because @get_pntr itself is marked 'readnone'.</div>

<div><br></div><div>Please file a bug.</div><div><br></div><div>Nick</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 22 May 2014 08:15, Robert Lougher <span dir="ltr"><<a href="mailto:rob.lougher@gmail.com" target="_blank">rob.lougher@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Philip,<br>
<br>
Thanks for the reply.<br>
<div class=""><br>
On 22 May 2014 01:31, Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br>
><br>
> On 05/21/2014 02:52 PM, Robert Lougher wrote:<br>
>><br>
>> On 21 May 2014 21:40, Robert Lougher <<a href="mailto:rob.lougher@gmail.com">rob.lougher@gmail.com</a>> wrote:<br>
>>><br>
>>> define i32* @get_pntr(i32* readnone %p) {<br>
>>> entry:<br>
>>>    ret i32* %p<br>
>>> }<br>
>>><br>
>>> define void @store(i32* nocapture readnone %p) {<br>
>>> entry:<br>
>>>    store i32 10, i32* %p, align 4, !tbaa !1<br>
>>>    ret void<br>
>>> }<br>
>>><br>
>> Further to my first post, based on the definition of readnone on an<br>
>> argument, this is also incorrect.  After get_pntr() has been inlined<br>
>> into store(), we are dereferencing %p, but it is still marked<br>
>> readnone.<br>
>><br>
>> So we seem to have a couple of issues.  First GVN seems to be making<br>
>> incorrect assumptions based on argument attributes, and secondly<br>
>> inlining can invalidate existing attributes?<br>
><br>
> I'm not clear on the GVN issue, but looking at your example IR, the readnone<br>
> attribute is definitely incorrect after inlining.<br>
><br>
<br>
</div>Yes.  I haven't investigated it any further, but the parameter was<br>
already readnone before inlining, so it looks like the attributes<br>
aren't revisited afterwards.  But that is just a guess.<br>
<div class=""><br>
> A question worth asking here: does this definition of readnone make sense?<br>
> I can see where it came from, but it seems to give very unintuitive<br>
> reasoning here.<br>
><br>
<br>
</div>Exactly.  That was my point in asking here before I went any further.<br>
The definition in the LangRef seems odd.  If it could still be<br>
accessed by another pointer, I can't see where the information is<br>
useful.<br>
<div class=""><br>
> p.s. Is this with TOT or an earlier version?<br>
<br>
</div>Yes, this was with TOT as of yesterday (r209294).<br>
<br>
Thanks,<br>
Rob.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Philip<br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>