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

[Daniel Berlin via llvm-commits]

On Sun, Sep 3, 2017 at 6:48 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> On 09/03/2017 08:35 PM, Daniel Berlin via llvm-commits wrote:
>
>
>>>
>>> I believe this follows from the GetUnderlyingObject and
>>> isIdentifiedObject related logic in  BasicAAResult::aliasCheck.
>>>
>>> And I'm not aware of any transforms in LLVM today that contradict the
>>> pointer aliasing rules.
>>>
>>
>> I assume you meant "do the wrong thing here". Which i still believe is
>> definitely wrong, FWIW, but i'm too lazy to go searching through bugzilla
>> some more today, so i'm going to let it go.
>>
>>
>> I'll also point out, you didn't read or write anything in your example.
> Which is strange to me because the usual semantic is "allowed to alias,
> but not allowed to be used to load/store".
> IE if you ask if the two pointers alias, the answer is yes.
> If you ask if a load can touch a given store, the answer is no.
>
> Here you are saying the pointer aliasing rules apply even to
> unwritten/unread pointers.
> That to me, is ... very strange.
>
>
> As far as I can tell, LLVM does not support pointer aliasing in the
> abstract.
>

Right, though i'll point out that applying the aliasing rules when there
are no memory accesses makes this very confusing, because it implies you
can't even form a pointer to a thing this way, which is *not* what i would
have taken away from the section on pointer aliasing from the langref.



> All queried memory locations are presumed to belong to some memory access.
> We may want to change this at some point.
>
>
It is what it is. It does give you a 0% chance of ever being able to use
aliasing to help with value equality (there are other issues).

It also means there are interesting ways to take noalias pointers and turn
them into aliasing pointers.  In most higher level languages, the pointers
*usually* never stopped aliasing in the first place, it was the
loads/stores that didn't conflict.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170903/c8a2b9d9/attachment.html>