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

[Sanjoy Das via llvm-commits]

On Sun, Sep 3, 2017 at 4:49 PM, Xinliang David Li <davidxl at google.com> wrote:
>> If we consider this to be a bug, then we can't fix it easily in SCEV
>> expander alone.  IIUC with your change in both the cases above `%ptr`
>> will be mapped into a `(add %p1 %p2)` SCEV expression, and so SCEV
>> expander will have to conservatively assume that `(add %p1 %p2)` came
>> from a `ptrtoint (add (inttoptr %p1) (inttoptr %p2))` (and have to
>> expand accordingly), and this will regress alias analysis.
>
> The original alias information is already conservative, isn't it? This does
> not seem to regress it.  By the way, a natural place to 'canonicalize' IR to
> get rid of the intptr/ptrint might actually be in SCEV itself. If that is
> the case,  teaching SCEV to understand them (possibly in a special mode as
> Hal mentioned) might be unavoidable.

If the original IR had the int<->ptr pattern then yes, the aliasing
information is already conservative (so a round trip through SCEV and
(conservative) SCEV expansion does not lose any information).

However, if the original IR had a GEP (and not int<->ptr) and a
SCEV->SCEVExpander round-trip gave us the ptrtoint version (which it
would have to with your change, since by looking at the SCEV
expression it can no longer determine whether the original IR used a
GEP or a ptr<->int), we'd have regressed aliasing information.

-- Sanjoy