[PATCH] D37419: Teach scalar evolution to handle inttoptr/ptrtoint

[Daniel Berlin via llvm-commits]

On Sun, Sep 3, 2017 at 7:17 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>> Sanjoy's description of the current behavior is accurate.
>>
>
>
>
>> I see two ways of looking at this:
>>
>>  1. This is a bug.
>>  2. To allow this kind of inter-object addressing you need to use
>> inttoptr/ptrtoint.
>>
>>
> I'm fine with #2, i just feel like our rules are a little hodgepodge:)
>
>
>> I don't believe that it is possible for the current behavior to manifest
>> as a problem for C/C++ (and this is likely the same for most higher-level
>> languages).
>>
>
> I don't believe it is either - we've already stated we assume aliasing
> does not imply pointer equality and non-aliasing does not imply pointer
> inequality.
> If we did, this behaviour could.
>

Which means the weirdest discontinuity that occurs to me off the top of my
head is that we are treating malloc's like lifetime beginning operations in
a bunch of cases (GVN does this) , but if you call free on the pointer from
the gep in sanjoy's example, there is no way to know it could have ended
the lifetime of both p0 and p1 without a separate analysis.

It means things like this in memorydependenceanalysis:

  if (const CallInst *CI = isFreeCall(Inst, &TLI)) {
    // calls to free() deallocate the entire structure
    Loc = MemoryLocation(CI->getArgOperand(0));
    return MRI_Mod;
  }
will say this free does not touch p1, even though it could have destroyed
it and ended the lifetime.

Do we have anything that takes advantage and does something silly? I don't
think we have anything that advanced ATM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170903/21702d8a/attachment.html>