When 'dest' and 'src' overlap, the boot time memcpy() calls memmove(),
which tests the same condition again.  GCC does not optimise it for now.
Let's split the copy part of memmove() as ____memmove() and call it from
memcpy().

Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
---
 arch/x86/boot/compressed/string.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/x86/boot/compressed/string.c b/arch/x86/boot/compressed/string.c
index 81fc1eaa3..4c0edb5d6 100644
--- a/arch/x86/boot/compressed/string.c
+++ b/arch/x86/boot/compressed/string.c
@@ -50,26 +50,31 @@ void *memset(void *s, int c, size_t n)
 	return s;
 }
 
-void *memmove(void *dest, const void *src, size_t n)
+void *____memmove(void *dest, const void *src, size_t n)
 {
 	unsigned char *d = dest;
 	const unsigned char *s = src;
 
-	if (d <= s || d - s >= n)
-		return ____memcpy(dest, src, n);
-
 	while (n-- > 0)
 		d[n] = s[n];
 
 	return dest;
 }
 
-/* Detect and warn about potential overlaps, but handle them with memmove. */
+void *memmove(void *dest, const void *src, size_t n)
+{
+	if (dest <= src || dest - src >= n)
+		return ____memcpy(dest, src, n);
+
+	return ____memmove(dest, src, n);
+}
+
+/* Detect and warn about potential overlaps, but handle them with ____memmove(). */
 void *memcpy(void *dest, const void *src, size_t n)
 {
 	if (dest > src && dest - src < n) {
 		warn("Avoiding potentially unsafe overlapping memcpy()!");
-		return memmove(dest, src, n);
+		return ____memmove(dest, src, n);
 	}
 	return ____memcpy(dest, src, n);
 }
-- 
2.30.2

On 1/22/22 17:58, Kuniyuki Iwashima wrote:
> -void *memmove(void *dest, const void *src, size_t n)
> +void *____memmove(void *dest, const void *src, size_t n)
>   {
>   	unsigned char *d = dest;
>   	const unsigned char *s = src;
>   
> -	if (d <= s || d - s >= n)
> -		return ____memcpy(dest, src, n);
> -
>   	while (n-- > 0)
>   		d[n] = s[n];
>   
>   	return dest;
>   }

The ___ naming is pretty cruel.  Could we call it memmove_no_overlap() 
or memmove_unsafe()?  Surely we can put some *useful* bytes in the name 
rather than padding it out with _'s.  No need to perpetuate the 
____memcpy() naming.

Also, is this worth the churn?  It probably saves less than 10 
instructions, all of which are ridiculously cheap.  Is there a *reason* 
for this other than being a pure cleanup?

From:   Dave Hansen <dave.hansen@intel.com>
Date:   Mon, 24 Jan 2022 09:38:40 -0800
> On 1/22/22 17:58, Kuniyuki Iwashima wrote:
> > -void *memmove(void *dest, const void *src, size_t n)
> > +void *____memmove(void *dest, const void *src, size_t n)
> >   {
> >   	unsigned char *d = dest;
> >   	const unsigned char *s = src;
> >   
> > -	if (d <= s || d - s >= n)
> > -		return ____memcpy(dest, src, n);
> > -
> >   	while (n-- > 0)
> >   		d[n] = s[n];
> >   
> >   	return dest;
> >   }
> 
> The ___ naming is pretty cruel.  Could we call it memmove_no_overlap() 
> or memmove_unsafe()?  Surely we can put some *useful* bytes in the name 
> rather than padding it out with _'s.  No need to perpetuate the 
> ____memcpy() naming.

Sure.  I will rename it to memmove_unsafe() because it supports another
overlap case. (d > s)


> 
> Also, is this worth the churn?  It probably saves less than 10 
> instructions, all of which are ridiculously cheap.  Is there a *reason* 
> for this other than being a pure cleanup?

This is just for cleanup.

On Tue, Jan 25, 2022 at 07:14:47AM +0900, Kuniyuki Iwashima wrote:
> > Also, is this worth the churn?  It probably saves less than 10 
> > instructions, all of which are ridiculously cheap.  Is there a *reason* 
> > for this other than being a pure cleanup?
> 
> This is just for cleanup.

Was wondering the same thing, whether this is even worth the trouble.
I'm sure you can find real bugs to fix.

:-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette