<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 3, 2017 at 4:23 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
>>   %i0 = ptrtoint i8* %p0 to i64<br>
>>   %i1 = ptrtoint i8* %p1 to i64<br>
>>   %i2 = add i32 %i0, %i1<br>
>>   %ptr = inttoptr i64 %i2 to i8*<br>
>><br>
>> `%ptr` can alias both `%p0` and `%p1`.  However, if you round-trip `%ptr`<br>
>> through SCEV and SCEVExpander, then nothing stops SCEVExpander from<br>
>> expanding the SCEV for `%ptr` to<br>
>><br>
>>   %i0 = ptrtoint i8* %p0 to i64<br>
>>   %i1 = ptrtoint i8* %p1 to i64<br>
>>   %p0_ = inttoptr i64 %i0 to i8*<br>
>>   %ptr = getelementptr i8, i8* %p0_, i64 %p0<br>
><br>
>  you mean<br>
><br>
> %ptr = getelementptr i8, i8* %p0_, i64 %p1 ?<br>
<br>
</span>I should have written `%ptr = getelementptr i8, i8* %p0, i64 %i1`, but<br>
yes, what you said gets at the core of the idea.<br>
<span class=""><br>
>> and `%ptr` no longer aliases `%p1` (assume that we can prove `%p0`<br>
>> no-alias `%p1` in both the snippets).<br>
><br>
> This looks like a convincing example. Do you consider this a bug in the SCEV<br>
> expander to be fixed?<br>
<br>
</span>If we consider this to be a bug, then we can't fix it easily in SCEV<br>
expander alone.  IIUC with your change in both the cases above `%ptr`<br>
will be mapped into a `(add %p1 %p2)` SCEV expression, and so SCEV<br>
expander will have to conservatively assume that `(add %p1 %p2)` came<br>
from a `ptrtoint (add (inttoptr %p1) (inttoptr %p2))` (and have to<br>
expand accordingly), and this will regress alias analysis.  </blockquote><div><br></div><div>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. </div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think to<br>
properly handle this in general, we will need SCEV nodes for ptrtoint<br>
and inttoptr.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div></div>