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

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

Before we go down this route, can you describe the class of inputs you're trying to handle? I ask because, at least historically, we've thought of inttoptr/ptrtoint as anti-canonical. We've held the line against teaching AA, SCEV, etc. about them. Taking a quick look at your LoopVectorizer tests, it looks like mostly cases where integer variables, that are really pointers is disguise, are being used as induction variables. Could we aggressively canonicalize inttoptr/ptrtoint toward i8* and GEPs instead (in InstCombine or similar)? If that's possible, I'd much rather we do that. This will also have the advantage that AA might understand what's going on (as will SCEV will no changes there), and will enable additional optimizations.



================
Comment at: lib/Transforms/Scalar/AlignmentFromAssumptions.cpp:276
+        else
+          AAPtr = OpUnk->getValue();
+        break;
----------------
I'm not sure that this is correct: How do we know that AAPtr is a pointer value? The idea here is that there's some expression that looks like ptrtoint(ptr) + e1 + e2 + ..., and we want to separate it into (ptr, e1 + e2 + ...). If we update SCEV to look through ptrtoint, we can't do this in the same way. I imagine we need to write a visitor to pull out the underlying pointer, or we need to not use SCEV for this task.


https://reviews.llvm.org/D37419