<div dir="ltr"><div dir="ltr"><br><div>>      `call void llvm.assume(i1 true) ["noundef"(type* %ptr), <br></div><div>> "noundef"(type2* %ptr2)]`</div><div><br></div><div>Maybe I can try this first, thanks.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 22, 2020 at 11:47 AM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">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"><br>
On 9/21/20 9:41 PM, Juneyoung Lee wrote:<br>
> Thank you for the infos; it seems making it raise UB is problematic.<br>
><br>
> Would clarifying it in LangRef be good? I can update the patch to contain<br>
> the information instead.<br>
<br>
Yes, please.<br>
<br>
<br>
> Another concern is then, how can we efficiently encode an assumption that a<br>
> pointer variable in IR does not have undef bits?<br>
> Certainly, in the front-end language, (most of) pointers won't have undef<br>
> bits, and it would be great if the information is still available in IR.<br>
> A pointer argument can be encoded using noundef, but, e.g., for a pointer<br>
> that is loaded from memory, such information disappears.<br>
> I think this information is helpful reducing the cost of fixing existing<br>
> undef/poison-related optimizations, because we can conclude that we don't<br>
> need to insert freeze in more cases.<br>
<br>
I thought we solved that already:<br>
<br>
     `call void llvm.assume(i1 true) ["noundef"(type* %ptr), <br>
"noundef"(type2* %ptr2)]`<br>
<br>
See <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html</a><br>
<br>
Is that enough for your needs?<br>
<br>
<br>
~ Johannes<br>
<br>
<br>
> Juneyoung<br>
><br>
><br>
> On Tue, Sep 22, 2020 at 5:51 AM Johannes Doerfert <<br>
> <a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br>
><br>
>> 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>
><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><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>