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

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 3 18:48:15 PDT 2017


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. All queried memory locations are presumed to belong to some 
memory access. We may want to change this at some point.

  -Hal

>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170903/0b974ccd/attachment.html>


More information about the llvm-commits mailing list