[PATCH] D20665: Claim NoAlias if two GEPs index different fields of the same struct

[Daniel Berlin via llvm-commits]

His point is that types in GEP's are just suggestions (see the GEP faq).

The type itself is meaningless.  You can take the result, bitcast it to a
int*, whatever.

You can also take an int *, bitcast it to a struct, gep it, and use the
result.


On Wed, Jun 1, 2016 at 5:29 PM, Taewook Oh <twoh at fb.com> wrote:

> twoh added inline comments.
>
> ================
> Comment at: llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp:842
> @@ +841,3 @@
> +  // of the same struct, they do not alias.
> +  if (GEP1->isInBounds() && GEP2->isInBounds()) {
> +    auto Opi1 = GEP1->op_begin() + 1;
> ----------------
> eli.friedman wrote:
> > You aren't allowed to make aliasing assumptions based on the type of a
> GEP; it's just pointer math.  "inbounds" just means that the result has to
> be in bounds relative to the allocation as a whole.  See
> http://llvm.org/docs/LangRef.html#getelementptr-instruction .
> >
> > Even if a frontend generates "nice" code, LLVM itself performs
> transformations which will break any assumptions based on the type of a GEP
> (for example, LLVM will transform a bitcast into a GEP).
> @eli.friedman Thanks for the comment. I'm afraid I didn't understand the
> point of your comments. This patch is for the case where two GEPs have the
> same pointer operand and access through the same indices until a certain
> point. For such case, not only types, but also indexed values should be
> identical at that point. If so, when the next index values are different,
> it means that two GEPs will point different fields of the same struct.
>
> It would be great if you could suggest an example that this patch
> generates wrong result.
>
>
> Repository:
>   rL LLVM
>
> http://reviews.llvm.org/D20665
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160601/babbc479/attachment.html>