[PATCH] D100717: [InstCombine] Transform memcpy to ptr load/stores if TBAA says so

Mon Apr 26 08:17:02 PDT 2021

lebedev.ri added a comment.

In D100717#2716833 <https://reviews.llvm.org/D100717#2716833>, @fhahn wrote:

> In D100717#2713553 <https://reviews.llvm.org/D100717#2713553>, @penzn wrote:
>
>> In D100717#2698680 <https://reviews.llvm.org/D100717#2698680>, @jdoerfert wrote:
>>
>>> I read through the code and I'm not sure if this is even a semantic change. I mean, can't we pick any
>>> type to do the memory transfer expansion? If so, TBAA metadata as a heuristic should be totally fine.
>>> We could also look at uses of the source and target pointers, for example. That said, we should write
>>> in the lang ref that we do use the TBAA names for heuristics and they should be chosen to match the code/intent.
>>
>> I agree with @nikic and @fhahn that we are trying to encode new information beyond what TBAA supposed to describe according to LangRef. I think vtable pointer handling is particularly telling - it benefits from special treatment, since it is not a "regular" pointer. Conceptually this change (along with vtable support) belong to the same problem space as encoding non-aliasing pointers (cough, Fortran).  In all this cases we need to know when something //is// a pointer, while //simulateneously// looking at the rules of source language to short-circuit optimization heuristics.
>>
>> Aside from may be generic pointer handling, I am not super comfortable in baking this kind of logic into the backend and would be interested in finding a better solution in the long run. Though the challenge is that different source languages have completely unrelated pointer rules, which would require different heuristics.
>
> Instead of using `!tbaa` as proxy for intent, couldn't we get the actual intent by looking at the users of the pointer?

No. <https://reviews.llvm.org/D88789>

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100717