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