src/lib/libmd/amd64, branch main FreeBSD source tree lib/libmd: import md5 amd64 kernels 2025-10-24T10:17:05+00:00 Robert Clausecker fuz@FreeBSD.org 2025-10-10T17:40:49+00:00 d92e987421001c365216b039f8c3303939c195f7 Differential Revision: https://reviews.freebsd.org/D45670 Reviewed by: imp Approved by: markj (mentor) MFC after: 1 month 
Differential Revision:	https://reviews.freebsd.org/D45670
Reviewed by:	imp
Approved by:	markj (mentor)
MFC after:	1 month
lib/libmd: fuz@freebsd.org -> fuz@FreeBSD.org 2025-10-24T10:16:21+00:00 Robert Clausecker fuz@FreeBSD.org 2025-10-10T20:25:47+00:00 ec3242ed1906e77c9af2c54da636833a946c62b6 Approved by: markj (mentor) MFC after: 1 week 
Approved by:	markj (mentor)
MFC after:	1 week
lib/libmd: reenable AVX2 SHA1 kernel 2025-06-04T10:28:03+00:00 Robert Clausecker fuz@FreeBSD.org 2025-06-04T10:00:05+00:00 a3ed55ff181827ef1541e3ed25c76844bc835ad8 Following jrtc27@'s fix of the transcribed code, it seems to work fine now. See also: 207f3b2b25eaa0f9d32699e664b139e5e40e5450 
Following jrtc27@'s fix of the transcribed code, it seems to work
fine now.

See also:	207f3b2b25eaa0f9d32699e664b139e5e40e5450
libmd: Fix amd64 AVX2 SHA-1 transcription errors 2025-06-03T01:46:57+00:00 Jessica Clarke jrtc27@FreeBSD.org 2025-06-03T01:46:57+00:00 207f3b2b25eaa0f9d32699e664b139e5e40e5450 This source was manually transcribed from Go's assembly syntax into FreeBSD's. Some differences exist (e.g. around stack frame allocation, but also some upstream LEAL instructions were replaced with ADDL here as getting the 64-bit super-registers of 32-bit isn't so doable, unlike Go) that were intended, but a few errors crept in. Fix these, found by comparing post-processed disassembly[1] (handling the ADDL difference above, and due to Go's assembler not optimising VP[X]OR encoding by commuting operands when it would give rise to a 2-byte VEX prefix) of a built copy of the corresponding Go source against ours. [1] In Vim: %g/\<vpx\?or\>/s/\(%ymm\([89]\|1[0-5]\)\), %ymm\([0-7]\), %ymm/%ymm\3, \1, %ymm/g (to commute the VP[X]OR operands as LLVM does) %s/\<leal\>\([[:space:]]\+\)(%r\(..\),%r\(..\)), %e\2/addl\1%e\3, %e\2/ (to convert LEAL to ADDL in the cases we do) %s/%e12\>/%r12d/g (as the previous conversion turns %r12 into %e12 not %r12d) Fixes: 8b4684afcde3 ("lib/libmd: add optimised SHA1 implementations for amd64") 
This source was manually transcribed from Go's assembly syntax into
FreeBSD's. Some differences exist (e.g. around stack frame allocation,
but also some upstream LEAL instructions were replaced with ADDL here as
getting the 64-bit super-registers of 32-bit isn't so doable, unlike Go)
that were intended, but a few errors crept in. Fix these, found by
comparing post-processed disassembly[1] (handling the ADDL difference
above, and due to Go's assembler not optimising VP[X]OR encoding by
commuting operands when it would give rise to a 2-byte VEX prefix) of a
built copy of the corresponding Go source against ours.

[1] In Vim:
    %g/\<vpx\?or\>/s/\(%ymm\([89]\|1[0-5]\)\), %ymm\([0-7]\), %ymm/%ymm\3, \1, %ymm/g
    (to commute the VP[X]OR operands as LLVM does)
    %s/\<leal\>\([[:space:]]\+\)(%r\(..\),%r\(..\)), %e\2/addl\1%e\3, %e\2/
    (to convert LEAL to ADDL in the cases we do)
    %s/%e12\>/%r12d/g
    (as the previous conversion turns %r12 into %e12 not %r12d)

Fixes:	8b4684afcde3 ("lib/libmd: add optimised SHA1 implementations for amd64")
lib/libmd: disable SHA1 AVX2 kernel 2025-06-02T23:27:00+00:00 Robert Clausecker fuz@FreeBSD.org 2025-06-02T22:54:32+00:00 e698e4a537736f6a7dd9a386e00997d7fb08e83f Seems like there is a bug lurking somewhere in the code. This was not caught during my testing. Disable the affected kernel for now while I figure out what is wrong with it. To reproduce, run jot -s '' -b 'a' -n 1000000 | sha1 This should yield 34aa973cd4c4daa4f61eeb2bdbad27316534016f, but gives fe161a71d7941e3d63a9cacadc4f20716a721944 with the broken code. Only the amd64/avx2 kernel is affected, the others seem to operate correctly. Reported by: olivier Fixes: 8b4684afcde3930eb49490f0b8431c4cb2ad9a46 
Seems like there is a bug lurking somewhere in the code.  This was not
caught during my testing.  Disable the affected kernel for now while I
figure out what is wrong with it.

To reproduce, run

    jot -s '' -b 'a' -n 1000000 | sha1

This should yield 34aa973cd4c4daa4f61eeb2bdbad27316534016f, but gives
fe161a71d7941e3d63a9cacadc4f20716a721944 with the broken code.  Only the
amd64/avx2 kernel is affected, the others seem to operate correctly.

Reported by:	olivier
Fixes:		8b4684afcde3930eb49490f0b8431c4cb2ad9a46
lib/libmd: add optimised SHA1 implementations for amd64 2025-05-14T23:39:58+00:00 Robert Clausecker fuz@FreeBSD.org 2024-05-28T15:20:41+00:00 8b4684afcde3930eb49490f0b8431c4cb2ad9a46 Three implementations are provided: one using just scalar instructions, one using AVX2, and one using the SHA instructions (SHANI). The AVX2 version uses a complicated multi-block carry scheme described in an Intel whitepaper; the code was carefully transcribed from the implementatio shipped with the Go runtime. The performance is quite good. From my Tiger Lake based NUC: old: 16.7s ( 613 MB/s) scalar: 14.5s ( 706 MB/s) avx2: 10.5s ( 975 MB/s) shani: 5.6s (1829 MB/s) Reviewed by: getz Obtained from: https://github.com/golang/go/blob/b0dfcb74651b82123746273bbf6bb9988cd96e18/src/crypto/sha1/sha1block_amd64.s Differential Revision: https://reviews.freebsd.org/D45444 
Three implementations are provided: one using just scalar
instructions, one using AVX2, and one using the SHA instructions
(SHANI).  The AVX2 version uses a complicated multi-block carry
scheme described in an Intel whitepaper; the code was
carefully transcribed from the implementatio shipped with the
Go runtime.  The performance is quite good.  From my Tiger Lake
based NUC:

old:    16.7s ( 613 MB/s)
scalar: 14.5s ( 706 MB/s)
avx2:   10.5s ( 975 MB/s)
shani:   5.6s (1829 MB/s)

Reviewed by:	getz
Obtained from:	https://github.com/golang/go/blob/b0dfcb74651b82123746273bbf6bb9988cd96e18/src/crypto/sha1/sha1block_amd64.s
Differential Revision:	https://reviews.freebsd.org/D45444