tstellar 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 doesn't look like glibc does anything like this; do you know > of a C standard library implementation that does? > > If we want to follow that path, then we'll presumably (eventually) want > address-space-`_overloaded` versions of all lib builtins that take pointers > -- looks like that's around 60 functions total. That said, I do wonder how > many of the functions in question that we're implicitly overloading on > address space actually support such overloading -- certainly any of them that > we lower to a call to a library function is going to go wrong at runtime. > > +@tstellar, who added this functionality in r233706 -- what was the intent > here? The goal of this patch was to avoid having to overload all the builtin with address spaces, which would be a lot of new builtins, but this functionality was added for targets that do not have a memcpy lib call, so I didn't consider the case where a libcall would be emitted. 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
