[llvm-dev] inttoptr->add->ptrtoint capturing pointer?

[Johannes Doerfert via llvm-dev]

On 2/18/21 11:40 AM, Jeroen Dobbelaere wrote:
>> How will inttoptr work with the new restrict patches?  Certainly the int2ptr capturing shouldn't nullify the restrict qualifier.
> The full restrict patches see through 'inttoptr(ptrtoint( x ) )', Besides that, the analysis stops at 'ptr2int(x)' and 'anything can happen'.
> Because of this, all other 'inttoptr' usages will never introduce a restrict provenance.
>
> (aka, a restrict pointer converted to an int + some computations and then converted back to a pointer will normally not retain the 'restrictness' and that can trigger undefined behavior)

I'm very concerned about looking through `int2ptr(ptr2int(x))`. I'd need 
to go back to our old conversations and examples though.
 From memory, I would think there can be a problem even if the pattern 
is as simple as that, e.g., if the ptr2int has more users
(which might only be other int2ptr's).

This is a very delicate part that has the tendency to break all our 
"smarts".

~ Johannes


>
> Greetings,
>
> Jeroen Dobbelaere
>
> From: Ryan Taylor <ryta1203 at gmail.com>
> Sent: Thursday, February 18, 2021 18:31
> To: Johannes Doerfert <johannesdoerfert at gmail.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Jeroen Dobbelaere <dobbel at synopsys.com>; Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr>; Philip Reames <listmail at philipreames.com>
> Subject: Re: [llvm-dev] inttoptr->add->ptrtoint capturing pointer?
>
> Juneyoung said he hadn't started working on it yet, so I'm going to take a look at it also.
>
> How will inttoptr work with the new restrict patches?  Certainly the int2ptr capturing shouldn't nullify the restrict qualifier.
>
> Thanks.
>
>
>
>
>
> On Thu, Feb 18, 2021 at 12:04 PM Johannes Doerfert <johannesdoerfert at gmail.com<mailto:johannesdoerfert at gmail.com>> wrote:
> I think you are working with a custom llvm here but I will
> make a few general statements that might help:
>
> - The noalias intrinsic as you've shown it captures, unfortunately.
>     We don't have the `nocapture_maybe_returned` attribute in IR yet that
> the Attributor uses for these situations,
>     IIRC, Juneyoung is working on making it an LLVM-IR enum attribute
> already.
>
> - int2ptr is assumed to capture in basically every analysis I've seen.
> It doesn't intrinsically but it is really
>     hard to get it right. That said, we could allow *very* special
> patterns but I would argue those should be recognized
>     in instcombine and replaced there.
>
> - Philip and I are working to define capture better for the lang ref, we
> might want to include some examples and
>     rational around int2ptr when we have a coherent model.
>
> I've CC'ed people that might correct me or augment my answer, hope this
> helps :)
>
> ~ Johannes
>
>
> On 2/18/21 9:17 AM, Ryan Taylor via llvm-dev wrote:
>> I have an example:
>>
>> foo(float * restrict y, int off1, int off2) {
>>     float * restrict x;
>>     for (..) {
>>       for (..) {
>>         x = y+off1;
>>       }
>>       x = (const float *)((int)x+off2))
>>
>> I'm not sure why this should be capturing the pointer?
>>
>> For instance, looking at scoped noalias dbg info:
>>
>> SNA: Capture check for B/CSB UO:   %54 = inttoptr i32 %add83 to float*,
>> !dbg !101
>> SNA: Pointer   %1 = call float* @llvm.noalias.p0_float(float* %0, metadata
>> !38), !dbg !41 might be captured!
>>
>> Is this implying that the noalias intrinsic might be capturing the pointer?
>> It doesn't look like "noalias" intrinsic has NoCapture property on the
>> pointer:
>>
>> def int_noalias       : Intrinsic<[llvm_anyptr_ty],
>>                                     [LLVMMatchType<0>, llvm_metadata_ty],
>>                                     [IntrArgMemOnly, Returned<0>]>;
>>
>> It should though right? From the definition of capture it is returning the
>> pointer; however, we know nothing is happening here.
>>
>> I'm on llvm 10 with Hal's restrict patches.
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!A4F2R9G_pg!Pm5BQtdh_gU6pe-WvhApIs2FOjI1V7vJDj6H93m0sNUItsa5T6CbzW5JL1cixruSF_kY7ywW$>