Re: Fixing inline expansion of overlapping memmove and non-overlapping memcpy

[Jakub Jelinek <jakub@redhat.com>]

On Wed, May 15, 2019 at 11:23:54AM -0500, Aaron Sawdey wrote:
> We currently have gimple_fold_builtin_memory_op() figuring out where there
> is no overlap and converging __builtin_memmove() to __builtin_memcpy(). Would
> you forsee looking for converting __builtin_memmove() with overlap into
> a call to __builtin_memmove_hint if it is a case where we can define the

Please do not introduce user visible builtins that you are not intending to
support for user use.  Thus, I think you want internal function
.MEMMOVE_HINT as opposed to __builtin_memmove_hint.

> overlap precisely enough to provide the hint? My guess is that this wouldn't
> be a very common case.
> 
> My goals for this are:
>  * memcpy() call becomes __builtin_memcpy and goes to optab[cpymem]
>  * memmove() call becomes __builtin_memmove (or __builtin_memcpy based
>    on the gimple analysis) and goes through optab[movmem] or optab[cpymem]

Except for the becomes part (the memcpy call is the same thing as
__builtin_memcpy in the middle-end, all you care about if it is
BUILT_IN_MEMCPY etc. and whether it has compatible arguments), and for the
missing optab[movmem] part and movmem->cpymem renaming, isn't that what we
have already?

	Jakub