[PATCH] D79279: Add overloaded versions of builtin mem* functions

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D79279#2200916 <https://reviews.llvm.org/D79279#2200916>, @rsmith wrote:

> In D79279#2197176 <https://reviews.llvm.org/D79279#2197176>, @rjmccall wrote:
>
>> I thought part of the point of `__builtin_memcpy` was so that C library headers could do `#define memcpy(x, y, z) __builtin_memcpy(x, y, z)`.  If so, the conformance issue touches `__builtin_memcpy` as well, not just calls to the library builtin.
>
> They would have to declare it as well (because C code can `#undef memcpy` and expect to then be able to call a real function), so the `#define` would be pointless.

It wouldn't be pointless; it would enable optimization of direct calls to memcpy (the 99% case) without the compiler having to special-case a function by name.  And you don't need an `#undef`, since `&memcpy` doesn't trigger the preprocessor when `memcpy` is a function-like macro.  I seem to remember this being widely used in some math libraries, but it's entirely possible that it's never been used for `memcpy` and the like.  It's also entirely possible that I'm passing around folklore.

If we just want memcpy to do the right thing when called directly, that's not ridiculous.  I don't think it would actually have any conformance problems: a volatile memcpy is just a less optimizable memcpy, and to the extent that an address-space-aware memcpy is different from the standard definition, it's probably UB to use the standard definition to copy memory in non-generic address spaces.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79279