[PATCH] D30225: [LIR] re-enable generation of memmove with runtime checks

Sebastian Pop via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 21 17:54:27 PST 2017


sebpop added a comment.

In https://reviews.llvm.org/D30225#683038, @efriedma wrote:

> Why are we generating a runtime check for memmove, as opposed to memcpy?


LIR is very conservative: it will generate a memcpy only when it knows that source and destination do not alias.
When the check for alias fails, this patch adds the needed checks to ensure that the dependence is in the right direction: WAR deps are ok to memmove, RAW deps are unsafe: see comments in the code https://bugs.llvm.org//show_bug.cgi?id=31391#c4
Of course we could add one more check to generate more memcpys than memmoves (when the number of bytes copied is less than the difference between source and destination).

> I mean, they're the same function on many platforms, but we inline calls to memcpy much more aggressively for small sizes, so there could be a performance benefit to generating llvm.memcpy instead of llvm.memmove.

Right.  If you tell me to add that check, I'll add it.

> Does it make sense to perform this transform as part of the loop-idiom pass?  loop-idiom runs interleaved with inlining; inserting runtime checks before we inline a function seems like a bad idea.

What is your suggestion?


Repository:
  rL LLVM

https://reviews.llvm.org/D30225





More information about the llvm-commits mailing list