<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> I also don't understand "  // It's tempting to handle inttoptr and ptrtoint<br>
> as no-ops, however this can<br>
>   // lead to pointer expressions which cannot safely be expanded to GEPs,<br>
>   // because ScalarEvolution doesn't respect the GEP aliasing rules when<br>
>   // simplifying integer expressions."<br>
><br>
> 1. What are "the gep aliasing rules", exactly?<br>
> <a href="https://llvm.org/docs/LangRef.html#pointeraliasing" rel="noreferrer" target="_blank">https://llvm.org/docs/LangRef.<wbr>html#pointeraliasing</a> does not mention special<br>
> rules for gep :)<br>
<br>
</span>I think the rule it is talking about is that reads and writes on a GEP<br>
are allowed to only read from and write to the allocation that is<br>
passed in as the first parameter to the GEP</blockquote><div>When we had the discussion about "inrange" and "inbounds", (and elsewhere, like field accesses) it was raised repeatedly that it's just fine to gep outside what would be the normal "range" of a pointer, because you can't ever really tell what it is.</div><div>IE a gep of a given pointer can access anything it wants.<br></div><div> </div><div>In fact, it seemed generally accepted that you can happily GEP from a pointer to anywhere you want unless there's an inrange or inbounds on it.</div><div>So i'm not sure what you mean by "the allocation", since none of these allocations are  defined in terms of llvm memory semantics (IE they aren't alloca's, they are malloc/frees).</div><div><div>If that's not the case, we are not being consistent (IE we're losing optimizations we shouldn't, and we have correctness issues we don't think we do).</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> -- you can't GEP from one<br>
allocation to another different allocation and issue reads/writes.  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> So<br>
my statement above was imprecise, `%p0` no-alias `%p1` is not<br>
sufficient to infer no-alias in the GEP case, you'd have to know that<br>
`%p0` and `%p1` are different allocations (based off different malloc<br>
or alloca, for instance).</blockquote><div>  </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I think the pointer aliasing rules have a typo (which I'll fix), but<br>
in principle this follows from:<br>
<br>
"Any memory access must be done through a pointer value associated<br>
with an address range of the memory access, otherwise the behavior is<br>
undefined. Pointer values are associated with address ranges according<br>
to the following rules"<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
"A pointer value is associated with the addresses associated with any<br>
value it is based on."<br>
<br>
"A pointer value formed from a getelementptr operation is based on the<br>
second [should be *first*] value operand of the getelementptr."<br></blockquote><div><br></div><div><br></div><div>This set of rules, without anything more, implies we have both correcntess and optimization issues :)</div><div><br></div><div><br></div><div><br></div></div></div></div>