[PATCH] D37419: Teach scalar evolution to handle inttoptr/ptrtoint

[Sanjoy Das via Phabricator via llvm-commits]

sanjoy requested changes to this revision.
sanjoy added a comment.
This revision now requires changes to proceed.

Hi David,

Generally it is not safe to look through `inttoptr` and `ptrtoint` in SCEV.  https://github.com/llvm-mirror/llvm/blob/master/lib/Analysis/ScalarEvolution.cpp#L6053 has a little bit of the rationale, but basically the problem is that in:

  %i0 = ptrtoint i8* %p0 to i64
  %i1 = ptrtoint i8* %p1 to i64
  %i2 = add i32 %i0, %i1
  %ptr = inttoptr i64 %i2 to i8*

`%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

  %i0 = ptrtoint i8* %p0 to i64
  %i1 = ptrtoint i8* %p1 to i64
  %p0_ = inttoptr i64 %i0 to i8*
  %ptr = getelementptr i8, i8* %p0_, i64 %p0

and `%ptr` no longer aliases `%p1` (assume that we can prove `%p0` no-alias `%p1` in both the snippets).

In other words, `ptrtoint` and `inttoptr` are not the same as `bitcast` since the former two have aliasing implications while the latter does not.

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.


https://reviews.llvm.org/D37419