[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5672845ec66744df9ee0f0c56031ab00@AcuMS.aculab.com>
Date: Fri, 30 Sep 2022 09:55:27 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Nick Desaulniers' <ndesaulniers@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>
CC: "x86@...nel.org" <x86@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Kees Cook <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"llvm@...ts.linux.dev" <llvm@...ts.linux.dev>,
Andy Lutomirski <luto@...nel.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: RE: [PATCH v4] x86, mem: move memmove to out of line assembler
From: Nick Desaulniers
> Sent: 28 September 2022 22:05
...
> memmove is quite large and probably shouldn't be inlined due to size
> alone
..
> + /* Decide forward/backward copy mode */
> + cmpl dest, src
> + jb .Lbackwards_header
It has to be better to do the slightly more complicated
test 'dest - src < size' (as unsigned) so that reverse
copies are only done when absolutely necessary.
Ignoring pathological cases on some cpu families the
forwards copy will benefit from hardware cache prefetch.
I also have a vague recollection of std and cld being slow.
Oh - and why do all the labels have 'byteswap' in them?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists