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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
