<div dir="ltr">On Sat, Sep 21, 2013 at 2:32 PM, Benjamin Kramer <span dir="ltr"><<a href="mailto:benny.kra@gmail.com" target="_blank">benny.kra@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On 21.09.2013, at 01:28, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>
<br>
> On Fri, Sep 20, 2013 at 12:12 PM, Benjamin Kramer <<a href="mailto:benny.kra@gmail.com">benny.kra@gmail.com</a>> wrote:<br>
><br>
> On 20.09.2013, at 20:59, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>> wrote:<br>
><br>
> > On Fri, Sep 20, 2013 at 7:38 AM, Benjamin Kramer <<a href="mailto:benny.kra@googlemail.com">benny.kra@googlemail.com</a>> wrote:<br>
> > Author: d0k<br>
> > Date: Fri Sep 20 09:38:44 2013<br>
> > New Revision: 191090<br>
> ><br>
> > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=191090&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=191090&view=rev</a><br>
> > Log:<br>
> > InstCombine: Canonicalize (gep i8* X, -(ptrtoint Y)) to (sub (ptrtoint X), (ptrtoint Y))<br>
> ><br>
> > The GEP pattern is what SCEV expander emits for "ugly geps". The latter is what<br>
> > you get for pointer subtraction in C code. The rest of instcombine already<br>
> > knows how to deal with that so just canonicalize on that.<br>
> ><br>
> ><br>
> ><br>
> > Is this really a good idea?  We lose aliasing information from turning the GEP into a sub, and it seems like it could easily trigger on regular C++ code.  (If the only user of the GEP is a ptrtoint, it's a different story, but you're not checking that.)<br>

><br>
> I was thinking the same first, but does subtracting two pointers and using the result as a pointer really make sense? I can't see how that would be useful.<br>
><br>
><br>
> No, but just because we see a ptrtoint doesn't mean Y is actually represents a pointer.<br>
<br>
</div></div>And how do non-pointers disguised as pointers affect aliasing? ;)<br>
<br><br></blockquote><div>The problem is that if alias analysis can't prove the RHS isn't a pointer, we lose the special aliasing guarantee that a GEP is only based on its LHS.<br><br></div><div>Might not be important in practice, though.<br>
</div><div><br></div><div>-Eli<br></div></div></div></div>