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> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161223/0f80b913/attachment.html>
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. Piotr> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161223/d11d4d6a/attachment.html>
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/l >> ib/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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161223/b06b7377/attachment.html>