<div dir="ltr">Thank you for the infos; it seems making it raise UB is problematic.<div><div><br></div><div>Would clarifying it in LangRef be good? I can update the patch to contain the information instead.</div><div><br></div><div>Another concern is then, how can we efficiently encode an assumption that a pointer variable in IR does not have undef bits?</div></div><div>Certainly, in the front-end language, (most of) pointers won't have undef bits, and it would be great if the information is still available in IR.</div><div>A pointer argument can be encoded using noundef, but, e.g., for a pointer that is loaded from memory, such information disappears.</div><div>I think this information is helpful reducing the cost of fixing existing undef/poison-related optimizations, because we can conclude that we don't need to insert freeze in more cases.</div><div><br></div><div>Juneyoung</div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 22, 2020 at 5:51 AM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">To be fair, if the address has to be `noundef` the example would just be <br>
UB. That said, I still believe it "is not".<br>
<br>
<br>
On 9/21/20 1:41 PM, Philip Reames wrote:<br>
> I think we need to allow this.  Otherwise, we have to prove that <br>
> addresses are non-undef before we can hoist or sink a memory <br>
> instruction.  Today, aliasing can use things like known bits, and if <br>
> we imposed a no-undef in address requirement, we'd either need to <br>
> replace such reasoning in AA, or have passes which wish to hoist/sink <br>
> check the property afterwards.<br>
><br>
> Or to say it differently, I think it's reasonable for %p2 and %p3 to <br>
> be provably no alias and dereferenceable, and for %v and %v2 to be <br>
> safe to speculate.<br>
><br>
> %p = alloca [16 x i8]<br>
> %p2 = gep %p, (undef & 7)<br>
> %v = load %p2<br>
> %p3 = gep %p, 8<br>
> %v2 = load %p3<br>
><br>
> Keep in mind that the undef doesn't have to be literal and can be <br>
> arbitrarily obscured (e.g. behind a function call).  The alternative <br>
> interpretation is extremely limiting.<br>
><br>
> Philip<br>
><br>
><br>
> On 9/21/20 10:41 AM, Johannes Doerfert via llvm-dev wrote:<br>
>> My feeling tells me we should allows this.<br>
>> No proper justification handy but your example doesn't strike me as UB.<br>
>><br>
>> ~ Johannes<br>
>><br>
>><br>
>> On 9/21/20 12:32 PM, Eli Friedman via llvm-dev wrote:<br>
>>> I think it’s reasonable to expect that IR generated by frontends <br>
>>> doesn’t do this.<br>
>>><br>
>>> Not sure about transforms; I can imagine that we might speculate a <br>
>>> load without proving all the bits are well-defined.<br>
>>><br>
>>> -Eli<br>
>>><br>
>>> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of <br>
>>> Juneyoung Lee via llvm-dev<br>
>>> Sent: Sunday, September 20, 2020 3:54 PM<br>
>>> To: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
>>> Subject: [EXT] Re: [llvm-dev] Is it valid to dereference a pointer <br>
>>> that have undef bits in its offset?<br>
>>><br>
>>>> %p2 = gep %p, (undef & 8)<br>
>>> A silly typo: undef & 8 -> undef & 7<br>
>>><br>
>>> On Mon, Sep 21, 2020 at 7:47 AM Juneyoung Lee <br>
>>> <<a href="mailto:juneyoung.lee@sf.snu.ac.kr" target="_blank">juneyoung.lee@sf.snu.ac.kr</a><mailto:<a href="mailto:juneyoung.lee@sf.snu.ac.kr" target="_blank">juneyoung.lee@sf.snu.ac.kr</a>>> wrote:<br>
>>> Hello all,<br>
>>><br>
>>> Is it valid to dereference a pointer that has undef bits in its offset?<br>
>>><br>
>>> For example,<br>
>>><br>
>>> %p = alloca [8 x i8]<br>
>>> %p2 = gep %p, (undef & 8)<br>
>>> store 0, %p2<br>
>>><br>
>>> undef & 8 is always less than 8, so technically it will store zero <br>
>>> to one of the array's elements.<br>
>>><br>
>>> The reason is that I want to improve no-undef analysis by suggesting <br>
>>> that a pointer that is passed to load/store is well-defined, by <br>
>>> making it raise UB when a pointer with undef bits is given.<br>
>>><br>
>>> A suggested patch is here: <a href="https://reviews.llvm.org/D87994" rel="noreferrer" target="_blank">https://reviews.llvm.org/D87994</a><br>
>>><br>
>>> I wonder whether there is a case using this to do something that I'm <br>
>>> not aware.<br>
>>><br>
>>> Thanks,<br>
>>> Juneyoung<br>
>>><br>
>>><br>
>>> -- <br>
>>><br>
>>> Juneyoung Lee<br>
>>> Software Foundation Lab, Seoul National University<br>
>>><br>
>>> _______________________________________________<br>
>>> LLVM Developers mailing list<br>
>>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div>