[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

["wilco at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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;
}