[libc++] Replace std::memmove/memcpy with __builtin_memmove/memcpy

[Quuxplusone]

This allows us to eliminate some transitive includes of <cstring>, and also makes the whole codebase consistent with the style adopted in commit 5629d49 (D139235).

This is relevant to my interests because P1144 wants to use (__builtin_)memcpy inside std::swap, and if I'm able to use the new non-<cstring>-including style there, that'll shrink the P1144 diff. So it would be convenient to have this commit as confirmation that the new style is indeed acceptable everywhere — that there's not some subtle reason we're intentionally avoiding __builtin_memcpy in these other places.

[ldionne]

I like this patch because it increases the consistency of the code. However, I also dislike that we're moving to a lower-level, less standard API for calling these functions. The only reason why we've done that in 5629d49 is that we needed a constexpr-friendly version of memmove.

Other points in favor:

• This reduces the reliance on the C library, maybe making us closer to freestanding
• This reduces the number of headers we need to include

@var-const Do you have an opinion about this?

[ldionne]

I think we've been putting those at the end of headers, no? For example look at <string>. The reason is this helps avoid accidental dependencies and dependency cycles.

[ldionne]

Ok, I think I actually like this patch. I especially like that we stop relying so much on the C standard library -- I just came across a case where we specifically want to stop relying on it, in a freestanding-ish context.

Can you please run this through CI?

[Quuxplusone]

Looks like this strategy could also apply to __builtin_memcmp, which would remove some transitive includes of <cstring> from @philnik777's D139554.
...But, this whole idea is going to have trouble on GCC, because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70816 and friends. GCC's __builtin_mem{cmp,cpy,move} cannot handle bytes that happen to be owned by a constexpr std::string. https://godbolt.org/z/KjPYbWP8a
Also, MSVC supports __builtin_memcmp but not __builtin_mem{cpy,move}: if libc++ uses the builtins then we get further from MSVC-compatibility, rather than closer. I don't know how important that is.

This patch almost certainly requires more work than I can give it, I guess.

[philnik777]

I'm not a huge fan of this as-is. We often need to work around short-comings of the builtins, especially for constexpr execution. I'd be much more in favour of having __libcpp_ or __constexpr_ versions of C functions to have a central place where we can work around any problems, like we have for strlen (__constexpr_strlen).

[var-const]

@ldionne I like @philnik777's idea to introduce another layer of abstraction. It seems like it should help to deal with compiler divergence / unsupported stuff / etc. With that suggestion applied, I think it would allow us to be more efficient where possible while still providing an easy (and centralized) place for writing fallbacks.

[Quuxplusone]

Abandoning. Looks like at least part of this direction (the idea that we should have a set of std::__constexpr_memfoo entry points, named and used consistently) is being merged into https://reviews.llvm.org/D143329 .