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

[Sanjoy Das via llvm-commits]

Hi,

>>   %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
>
>  you mean
>
> %ptr = getelementptr i8, i8* %p0_, i64 %p1 ?

I should have written `%ptr = getelementptr i8, i8* %p0, i64 %i1`, but
yes, what you said gets at the core of the idea.

>> and `%ptr` no longer aliases `%p1` (assume that we can prove `%p0`
>> no-alias `%p1` in both the snippets).
>
> This looks like a convincing example. Do you consider this a bug in the SCEV
> expander to be fixed?

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.  I think to
properly handle this in general, we will need SCEV nodes for ptrtoint
and inttoptr.

-- Sanjoy