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

[Daniel Berlin via llvm-dev]

On Fri, Dec 23, 2016 at 10:02 PM, Chandler Carruth <chandlerc at google.com>
wrote:

> 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.
>

Based on what?


> I would teach things to understand GEPs with zero indices, it's pretty
> easy (we have tools to automate it).
>

So your position is that we should teach literally everything to understand
something new, instead of canonicalize in the direction literally
everything understands already?


>
> 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.
>
This is about the equivalence of gep 0,0 to bitcast. They aren't equivalent
to other types of geps, so reasoning about them seems very different and
orthogonal to me.
You are saying "well things *should* understand all constant GEP anyway".
That may or may not be true, but it's, IMHO, pretty orthogonal to how we
choose to canonicalize a given operation.
You are also suggesting representing an operation in something
significantly more complicated than it's direct form.

Also, can you provide some data?
You say "most" and "probably" with no explicit examples.
Can you pull out an explicit example of how it would help existing passes,
both optimization, and analysis, vs canonicalizing to bitcast?

Because i'll be honest, i'm not seeing it.  It seems like a more
complicated form, for no good reason.

It would be like canonicalizing  add's to xor's.  You can do it, and "most
things that reason about adds probably want to reason about xors".
However, i think we'd all agree that add is a much simpler and direct form,
and very directly represents the operation.
We should, IMHO, do the same here.  If something wants to see it as a GEP,
it can see it as a GEP.

Arguing that "well, passes should handle GEP anyway" is literally the same
as arguing "well, passes should understand xor anyway".



>
>
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/20161223/2ca60b67/attachment.html>