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

Mon Apr 26 08:12:53 PDT 2021

fhahn added a comment.

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?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100717