[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3de7cc4d-cb88-4107-9265-066cbedd4561@hogyros.de>
Date: Mon, 4 Aug 2025 13:44:21 +0900
From: Simon Richter <Simon.Richter@...yros.de>
To: Eric Biggers <ebiggers@...nel.org>, linux-crypto@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
"Jason A . Donenfeld" <Jason@...c4.com>, linux-mips@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org
Subject: Re: [PATCH 4/7] crypto: sparc/md5 - Remove SPARC64 optimized MD5 code
Hi,
On 8/4/25 05:44, Eric Biggers wrote:
> Taken together, it's clear that it's time to retire these additional MD5
> implementations, and focus maintenance on the MD5 generic C code.
[...]
> - ldd [%o1 + 0x00], %f8
> - ldd [%o1 + 0x08], %f10
> - ldd [%o1 + 0x10], %f12
> - ldd [%o1 + 0x18], %f14
> - ldd [%o1 + 0x20], %f16
> - ldd [%o1 + 0x28], %f18
> - ldd [%o1 + 0x30], %f20
> - ldd [%o1 + 0x38], %f22
> -
> - MD5
This is a literal CPU instruction that ingests sixteen registers (f8 to
f23) and updates the hash state in f0 to f3.
I can see the point of removing hand-optimized assembler code when a
compiler can generate something that runs just as well from generic
code, but this here is using CPU extensions that were made for this
specific purpose.
This is exactly the kind of thing you would point to as an argument why
asynchronous hardware offload support is unnecessary.
Simon
Powered by blists - more mailing lists