[PATCH] D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++
Alexandre Isoard via Phabricator via cfe-commits
cfe-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 cfe-commits
mailing list