[llvm] r191090 - InstCombine: Canonicalize (gep i8* X, -(ptrtoint Y)) to (sub (ptrtoint X), (ptrtoint Y))

Eli Friedman eli.friedman at gmail.com
Sun Sep 22 00:57:17 PDT 2013


On Sat, Sep 21, 2013 at 2:32 PM, Benjamin Kramer <benny.kra at gmail.com>wrote:

>
> On 21.09.2013, at 01:28, Eli Friedman <eli.friedman at gmail.com> wrote:
>
> > On Fri, Sep 20, 2013 at 12:12 PM, Benjamin Kramer <benny.kra at gmail.com>
> wrote:
> >
> > On 20.09.2013, at 20:59, Eli Friedman <eli.friedman at gmail.com> wrote:
> >
> > > On Fri, Sep 20, 2013 at 7:38 AM, Benjamin Kramer <
> benny.kra at googlemail.com> wrote:
> > > Author: d0k
> > > Date: Fri Sep 20 09:38:44 2013
> > > New Revision: 191090
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=191090&view=rev
> > > Log:
> > > InstCombine: Canonicalize (gep i8* X, -(ptrtoint Y)) to (sub (ptrtoint
> X), (ptrtoint Y))
> > >
> > > The GEP pattern is what SCEV expander emits for "ugly geps". The
> latter is what
> > > you get for pointer subtraction in C code. The rest of instcombine
> already
> > > knows how to deal with that so just canonicalize on that.
> > >
> > >
> > >
> > > 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.)
> >
> > 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.
> >
> >
> > No, but just because we see a ptrtoint doesn't mean Y is actually
> represents a pointer.
>
> And how do non-pointers disguised as pointers affect aliasing? ;)
>
>
> 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.

Might not be important in practice, though.

-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130922/036ea29d/attachment.html>


More information about the llvm-commits mailing list