[PATCH] D102255: [SelectionDAG] Generate scoped AA metadata when lowering memcpy.

Michael Liao via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 20 12:49:37 PDT 2021


hliao added a comment.

Just read the relevant threads and bugs reported on the change of allowing exact-overlap on `llvm.memcpy`. See the reference list at the end. Personally, I think it's OK to assume NoAlias added here. By allowing exact-overlap in `llvm.memcpy`, the most significant change is on the basic-aa, which must consider the case where the source and destination of `llvm.memcpy` is the same. The make senses at the IR level, where `llvm.memcpy` is treated as a single op as the exact-overlap means the copy is a no-op and won't always overwrite the destination memory. But, where we lower that copy into loads/stores, we say that loads/stores won't alias. That's fine as the order between loads and stores on the same offset (or location for the exact-overlap case) is established through the data dependency. In addition, the no-alias established here is a scoped one, which only applies to loads/stored from this `llvm.memcpy` only. It won't affect the AA result between them to loads/stores out of the scope. (This patch depends on https://reviews.llvm.org/D102215, which propagates scoped AA on mem ops into loads/stores after lowering.)

But, there are definitely issues where the backend may split/merge/narrow/widen memory operations. For split and narrow, they seem fine. I started to address the merge issue in https://reviews.llvm.org/D102821 to ensure the correct scoped AA is used on the merged stores or loads. For widen, mostly load widening, we have a quite tricky issue as the widening result, in most cases, doesn't care about extra content loaded from memory. They want to choose the widened one to maximize performance but we have the risk that simply reusing the scoped AA metadata may result in undesired behavior.

-

https://lists.llvm.org/pipermail/cfe-dev/2020-August/066614.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102255



More information about the llvm-commits mailing list