https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70140
Wilco <wilco at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wilco at gcc dot gnu.org --- Comment #3 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Martin Liška from comment #2) > I've just taken look at that and please confirm that I understand that > correctly: > > 1) we want to ideally a same function for expansion of memcpy and mempcpy, > where for later one we'll append calculation of return value (dest + n)? Yes, I think the current movmem expander does not deal with the return value so could be reused for mempcpy expansion. > 2) I'm bit confused with 'GLIBC currently inlines mempcpy into memcpy'. Do > is mean that you basically do not want to emit any call to mempcpy and > prefer rather: Yes. Ignoring GLIBC internals, mempcpy is used quite infrequently. As a result not many targets have added highly optimized implementations. The targets that do have the issue that mempcpy is typically not in the cache when called, while memcpy is more likely already cached. If there are targets that do not want this, we could add a target define. Note that I'm not concerned about the corner case of a mempcpy being tailcalled which isn't possible anymore after we optimize mempcpy into memcpy. In almost all targets mempcpy is a C function that calls memcpy, ie. you already have extra overhead on every mempcpy call. See glibc/string/mempcpy.c: void * MEMPCPY (void *dest, const void *src, size_t len) { return memcpy (dest, src, len) + len; }