[PATCH] D79279: Add overloaded versions of builtin mem* functions
Tom Stellard via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Aug 6 13:10:23 PDT 2020
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.
>
> + at 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
More information about the cfe-commits
mailing list