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

[Piotr Padlewski via llvm-dev]

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>