<div dir="ltr">You generally aren't going to be able to do anything without frontend info.<div>The one trick you can play is actually to use pointer alignment (if it's there).</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 1, 2016 at 7:44 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sanjoy added a subscriber: sanjoy.<br>
<span class=""><br>
================<br>
Comment at: llvm/trunk/lib/Analysis/BasicAliasAnalysis.cpp:842<br>
@@ +841,3 @@<br>
+  // of the same struct, they do not alias.<br>
+  if (GEP1->isInBounds() && GEP2->isInBounds()) {<br>
+    auto Opi1 = GEP1->op_begin() + 1;<br>
----------------<br>
</span><span class="">twoh wrote:<br>
> eli.friedman wrote:<br>
> > 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 <a href="http://llvm.org/docs/LangRef.html#getelementptr-instruction" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.html#getelementptr-instruction</a> .<br>
> ><br>
> > 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).<br>
> @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.<br>
><br>
> It would be great if you could suggest an example that this patch generates wrong result.<br>
</span>Yes I think Eli is right here, if you have<br>
<br>
```<br>
struct {<br>
  int arr_a[2];<br>
  int arr_b[2];<br>
};<br>
```<br>
<br>
then in LLVM IR the `-1` th element of `arr_b` is the `1` st element of `arr_a`.<br>
<br>
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?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D20665" rel="noreferrer" target="_blank">http://reviews.llvm.org/D20665</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div>