sys: Remove $FreeBSD$: one-line .c patternRemove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
Separate kernel crc32() implementation to its own header (gsb_crc32.h) andrename the source to gsb_crc32.c.This is a prerequisite of unifying kernel zlib instances.PR: 229763Submitted by: Yosh
Separate kernel crc32() implementation to its own header (gsb_crc32.h) andrename the source to gsb_crc32.c.This is a prerequisite of unifying kernel zlib instances.PR: 229763Submitted by: Yoshihiro Ota <ota at j.email.ne.jp>Differential Revision: https://reviews.freebsd.org/D20193
show more ...
x86/crc32_sse42.c: quiet unused function warningReviewed by: cemApproved by: markj (mentor)Sponsored by: Dell EMC IsilonDifferential Revision: https://reviews.freebsd.org/D11980
Use inline asm instead of unportable intrinsics for the SSE4 crc32optimization.This fixes building with gcc-4.2.1 (it doesn't support SSE4).gas-2.17.50 [FreeBSD] supports SSE4 instructions, so th
Use inline asm instead of unportable intrinsics for the SSE4 crc32optimization.This fixes building with gcc-4.2.1 (it doesn't support SSE4).gas-2.17.50 [FreeBSD] supports SSE4 instructions, so this doesn'tneed using .byte directives.This fixes depending on host user headers in the kernel.Fix user includes (don't depend on namespace pollution in <nmmintrin.h>that is not included now).The instrinsics had no advantages except to sometimes avoid compilerpessimixations. clang understands them a bit better than inline asm,and generates better looking code which also runs better for cem, butfor me it just at the same speed or slower by doing excessiveunrollowing in all the wrong places. gcc-4.2.1 also doesn't understandwhat it is doing with unrolling, but with -O3 somehow it does moreunrolling that helps.Reduce 1 of the the compiler pessimizations (copying a variable whichalready satisfies an "rm" constraint in a good way by being in memoryand not used again, to different memory and accessing it there. Forcecopying it to a register instead).Try to optimize the inner loops significantly, so as to run at fullspeed on smaller inputs. The algorithm is already very MD, and wastuned for the throughput of 3 crc32 instructions per cycle found onat least Sandybridge through Haswell. Now it is even more tuned forthis, so depends more on the compiler not rearranging or unrollingthings too much. The main inner loop for should have no difficultyruning at full speed on these CPUs unless the compiler unrolls it toomuch. However, the main inner loop wasn't even used for buffers smallerthan 24K. Now it is used for buffers larger than 384 bytes. Now itis not so long, and the main outer loop is used more. The newoptimization is to try to arrange that the outer loop runs in parallelwith the next inner loop except for the final iteration; then reducethe loop sizes significantly to take advantage of this.Approved by: cemNot tested in production by: bde
calculate_crc32c: Add SSE4.2 implementation on x86Derived from an implementation by Mark Adler.The fast loop performs three simultaneous CRCs over subsets of the databefore composing them. This
calculate_crc32c: Add SSE4.2 implementation on x86Derived from an implementation by Mark Adler.The fast loop performs three simultaneous CRCs over subsets of the databefore composing them. This takes advantage of certain properties ofthe CRC32 implementation in Intel hardware. (The CRC instruction takes 1cycle but has 2-3 cycles of latency.)The CRC32 instruction does not manipulate FPU state.i386 does not have the crc32q instruction, so avoid it there. Otherwisethe implementation is identical to amd64.Add basic userland tests to verify correctness on a variety of inputs.PR: 216467Reported by: Ben RUBSON <ben.rubson at gmail.com>Reviewed by: kib@, markj@ (earlier version)Sponsored by: Dell EMC IsilonDifferential Revision: https://reviews.freebsd.org/D9342