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

[Florian Hahn via Phabricator via llvm-commits]

fhahn added a comment.

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

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

That does not really answer my question for this specific case though I think (or I miss how this is related to this particular issue). IIUC the linked patch correctly, it undos converting pointer load/stores to integer ones if possible.

But my suggestion/question is the other way around: check if a pointer is used to load a pointer instead of checking if `tbaa` claims it should be treated as pointer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100717