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

[Daniel Berlin via llvm-commits]

You generally aren't going to be able to do anything without frontend info.
The one trick you can play is actually to use pointer alignment (if it's
there).


On Wed, Jun 1, 2016 at 7:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> sanjoy added a subscriber: sanjoy.
>
> ================
> 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;
> ----------------
> twoh wrote:
> > 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.
> Yes I think Eli is right here, if you have
>
> ```
> struct {
>   int arr_a[2];
>   int arr_b[2];
> };
> ```
>
> then in LLVM IR the `-1` th element of `arr_b` is the `1` st element of
> `arr_a`.
>
> Generally I don't think you can do much better than using
> `GEP::accumulateConstantOffset` if there is a trailing non-constant index.
> But maybe in cases like `GEP(PTR, 1, unknown, 4)` you can play some tricks
> with divisibility?
>
>
> 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/2f66f1f2/attachment.html>