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

Petr Penzin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 23 14:18:47 PDT 2021


penzn added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100717



More information about the llvm-commits mailing list