[PATCH] D96881: Avoid Bitcast-GEP fusion for void pointers

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 10 13:02:17 PST 2021


nikic added a comment.

In D96881#2617663 <https://reviews.llvm.org/D96881#2617663>, @lebedev.ri wrote:

> In D96881#2615088 <https://reviews.llvm.org/D96881#2615088>, @hjooybar2 wrote:
>
>> <...>
>
> (unless i'm not aware of a RFC newer than https://lists.llvm.org/pipermail/llvm-dev/2019-December/137684.html)
> I think my main point is being ignored:
> This fix is temporary. After the pointer types are gone from IR,
> the problem will reappear, because the GEP's will have pointer offsets,
> they won't know anything about structs,

Why would this problem reappear? The current transform is what violates opaque pointers, and this patch removes one instance where the transform is applied. The transform uses the origin pointer element type to construct a new GEP, which would not be possible if there are no pointer element types. The whole transform would go away if pointer element types are dropped.

The core problem in this particular case is that GEP's in LLVM are type based, instead of being simple arithmetic with provenance, which means that there is an infinite number of ways to write the same GEP, if you add some pointer casts around it. We use heuristics to pick the used GEP representation, and in this case the choice ends up being unfavorable (though possibly the new choice after this patch is unfavorable in other circumstances -- this is a problem we cannot really resolve without fundamentally changing the GEP representation.)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96881/new/

https://reviews.llvm.org/D96881



More information about the llvm-commits mailing list