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

[Daniel Berlin via llvm-dev]

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>