<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 3, 2017 at 12:09 PM, Sanjoy Das via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">sanjoy requested changes to this revision.<br>
sanjoy added a comment.<br>
This revision now requires changes to proceed.<br>
<br>
Hi David,<br>
<br>
Generally it is not safe to look through `inttoptr` and `ptrtoint` in SCEV.  <a href="https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/ScalarEvolution.cpp#L6053" rel="noreferrer" target="_blank">https://github.com/llvm-<wbr>mirror/llvm/blob/master/lib/<wbr>Analysis/ScalarEvolution.cpp#<wbr>L6053</a> has a little bit of the rationale, but basically the problem is that in:<br>
<br></blockquote><div><br></div><div>Heh, interestingly, that old comment is right below the changes I made, but I did not notice it :)</div><div><br></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">
  %i0 = ptrtoint i8* %p0 to i64<br>
  %i1 = ptrtoint i8* %p1 to i64<br>
  %i2 = add i32 %i0, %i1<br>
  %ptr = inttoptr i64 %i2 to i8*<br>
<br>
`%ptr` can alias both `%p0` and `%p1`.  However, if you round-trip `%ptr` through SCEV and SCEVExpander, then nothing stops SCEVExpander from expanding the SCEV for `%ptr` to<br>
<br>
  %i0 = ptrtoint i8* %p0 to i64<br>
  %i1 = ptrtoint i8* %p1 to i64<br>
  %p0_ = inttoptr i64 %i0 to i8*<br>
  %ptr = getelementptr i8, i8* %p0_, i64 %p0<br></blockquote><div><br></div><div> you mean</div><div><br></div><div>%ptr = getelementptr i8, i8* %p0_, i64 %p1 ?</div><div><br></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">
<br>
and `%ptr` no longer aliases `%p1` (assume that we can prove `%p0` no-alias `%p1` in both the snippets).<br></blockquote><div><br></div><div><br></div><div>This looks like a convincing example. Do you consider this a bug in the SCEV expander to be fixed?</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>
In other words, `ptrtoint` and `inttoptr` are not the same as `bitcast` since the former two have aliasing implications while the latter does not.<br>
<br>
We could fix this in SCEV with some representational changes, but before that I'd prefer exploring Hal's direction of avoiding generating `ptrtoint` and `inttoptr` altogether.<br></blockquote><div><br></div><div>Yes, I will look into the pass that generates the intptr/ptrint conversion first and see if it is possible to eliminate it. Will revisit this once we have more information.</div><div><br></div><div>thanks,</div><div><br></div><div>David</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>
<br>
<a href="https://reviews.llvm.org/D37419" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D37419</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>