[PATCH] D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++

Alexandre Isoard via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 7 23:37:26 PDT 2019


alexandre.isoard added a comment.

I'm not convinced by the approach.

Can it still recognize the loop idiom into memcpy implementation but use `memmove` (as only `memcpy` has been blacklisted)?
Can it do the same for `memmove` (for the case without overlap), and end-up with infinite recursion?

I have a feeling we should pick a stance:

- either not allow the compiler to lower a builtin to a call to the library; (my preferred choice, but I'm biased)
- or not allow the library to use compiler builtins (but LTO flow with the runtime library *already* linked smells like trouble if we go this way).

The reason for my bias is that I have a multi-memcpy codegen in the compiler to generate those two calls:

  memcpy(left,  in, n);
  memcpy(right, in, n);

with a single loop.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61634





More information about the llvm-commits mailing list