[LLVMdev] SCEV Question

[David Greene]

LLVM 2.7's ScalarEvolution.cpp has this scary comment:

  // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can
  // lead to pointer expressions which cannot safely be expanded to GEPs,
  // because ScalarEvolution doesn't respect the GEP aliasing rules when
  // simplifying integer expressions.

I think I understand what the comment is saying.  If a GEP has inbounds
or other properties, that information will be lost when casting to an
integer and back to a pointer.

Unfortunately, (as Dan G. well knows), our compiler does a lot of this
ptrtoint->arithmetic->inttoptr kind of thing.  I would like to clean
that up at some point but right now I'm trying to track down some
regressions in SCEV when we updated to 2.7.

With previous LLVM versions, we have been handling inttoptr as a no-op
cast and created a special SCEV expression type for ptrtoint.

For 2.7, I created a new inttoptr SCEV expression type and turn inttoptr
instructions into that.

Really all I need to get to work is add recurrences being recognized in
the face of these ptr->int->ptr conversions.  I don't really care if
they get turned into GEPs later.

My assumption is that while an inttoptr SCEV expression may be overkill
for this case (I can treat inttoptr as a no-op if I don't care about
conversion back to GEP) it shouldn't really hurt anything if I create an
inttoptr SCEV as long as the support for analysis (loop invariance,
etc.) is all there.

Basically, I want to make sure I'm not going to trip over any gotchas.
Are my assumptions reasonable?

Comments, warnings or flames?  :)

                           -Dave