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

[Daniel Berlin via llvm-commits]

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

>
>
> 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.
>
>
Actually, this is, IMHO,  worse than i initially thought.

So imagine we free %gep from sanjoy's example.

Right now, the above code (and elsewhere) will say that free does not MOD
%p1.  Even if the pointer is value equal to %p1

We already say malloc operates by returning new memory regardless of what
pointer value it returns.  Here, free is taking a pointer and we  are
saying it only modifies the memory that pointer can alias.

I can think of a few possibilities

1. Free operates by pointer value and not "abstract memory location", in
which case, the above code is wrong, as free will modify things that are
value equal, even if they do not alias. In this model, except through value
numbering or range analysis, you can't really ever tell what free has done,
it may mod/ref anything (and we have some bugs to fix).

Also now malloc returns abstract memory objects, but free doesn't really
destroy them

2. An attempt by free to destroy p1 is considered UB, and sanjoy's code,
with a free at the end cannot validly destroy p1.  I would have trouble
believing we are generating currently correct code in this model from any
of our frontends, but willing to be convinced (IE i would believe if i
added asserts to free calls that they are not value equal to anything llvm
considers the argument to noalias, it would fail)

3. Free is not mapped into our memory model, but malloc is.

Thoughts? Other possibilities?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170903/4540a020/attachment.html>