<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 3, 2017 at 5:08 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"><span class="">On Sun, Sep 3, 2017 at 4:49 PM, Xinliang David Li <<a href="mailto:davidxl@google.com">davidxl@google.com</a>> wrote:<br>
>> 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.<br>
><br>
> The original alias information is already conservative, isn't it? This does<br>
> not seem to regress it.  By the way, a natural place to 'canonicalize' IR to<br>
> get rid of the intptr/ptrint might actually be in SCEV itself. If that is<br>
> the case,  teaching SCEV to understand them (possibly in a special mode as<br>
> Hal mentioned) might be unavoidable.<br>
<br>
</span>If the original IR had the int<->ptr pattern then yes, the aliasing<br>
information is already conservative (so a round trip through SCEV and<br>
(conservative) SCEV expansion does not lose any information).<br>
<br>
However, if the original IR had a GEP (and not int<->ptr) and a<br>
SCEV->SCEVExpander round-trip gave us the ptrtoint version (which it<br>
would have to with your change, since by looking at the SCEV<br>
expression it can no longer determine whether the original IR used a<br>
GEP or a ptr<->int), we'd have regressed aliasing information.<br></blockquote><div><br></div><div>SCEV itself can be canonicalized plus one bit to show it if is commutable. If it is, generate the conservative/aliasing losing add form, otherwise generate the GEP form.</div><div><br></div><div>However I find this situation extremely rare to be worth the effort: a really deferencible pointer is used as an offset. If the pointer is not dereferenced, the false aliasing does not really matter.</div><div><br></div><div>David</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div></div>