[llvm-dev] [canonicalization] GEP 0, 0

[Chandler Carruth via llvm-dev]

On Fri, Dec 23, 2016 at 3:30 PM Daniel Berlin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Fri, Dec 23, 2016 at 2:31 PM, Piotr Padlewski via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> 2016-12-23 22:17 GMT+01:00 David Majnemer <david.majnemer at gmail.com>:
>
>
>
> On Fri, Dec 23, 2016 at 1:09 PM, Davide Italiano via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On Fri, Dec 23, 2016 at 1:01 PM, Piotr Padlewski
> <piotr.padlewski at gmail.com> wrote:
> >
> >
> > On Dec 23, 2016 19:47, "Daniel Berlin" <dberlin at dberlin.org> wrote:
> >
> > Define soon?
> > My guess is 1 year or less.
> > (I've already seen patches to start converting most remaining memdep
> uses,
> > like memcpy opt, licm, etc)
> >
> >
> > That's good. Anyway I already have a patch that is doing invariant group
> > dependence across BBs, so I guess it make sense to push it upstream to
> push
> > the bar higher.
> > But I think we are getting a little bit of topic - should gep 0 be
> > canonicalized to bitcast?
> >
>
> Are memdep/memssa the only possible passes that could benefit from
> such a canonicalization or you can think of other cases when this can
> be useful?
>
>
> We already canonicalize.  We canonicalize in the other direction:
> https://github.com/llvm-mirror/llvm/blob/master/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2024
>
>
> Intresting. So what is the right solution here? I can easily add handling
> of gep 0 to GVN, or maybe the code that you mentioned should be in SROA.
> If SROA is the only user of this transformation and I there are quiet a
> few passes that it hurts, then I would propose moving this logic to SROA
> and always canonicalize gep 0 to bitcast.
>
>
> +1
>
> This canonicalization seems like it's unlikely to help other passes, and
> definitely makes handling more complicated elsewhere.
>

-1
;]

I think it is very useful to be able to canonicalize on GEPs rather than
bitcasts. I would teach things to understand GEPs with zero indices, it's
pretty easy (we have tools to automate it).

One reason why is that most things that want to reason about all-zero GEPs
probably want to reason about all-constant GEPs as well. Certainly, I would
expect MemDep and things like invariant.group to survive all-constant GEPs
too.

Note that even this ambiguity of which direction to canonicalize will go
away with typeless pointers as we won't have to choose one or the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161224/4c46e8d2/attachment.html>