<div dir="ltr">His point is that types in GEP's are just suggestions (see the GEP faq).<div><br></div><div>The type itself is meaningless.  You can take the result, bitcast it to a int*, whatever.</div><div><br>You can also take an int *, bitcast it to a struct, gep it, and use the result.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 1, 2016 at 5:29 PM, Taewook Oh <span dir="ltr"><<a href="mailto:twoh@fb.com" target="_blank">twoh@fb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">twoh added inline comments.<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="">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>
</span>@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>
<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>