LibCrypto: Add x86 specific versions of SHA1 and SHA2

[Hendiadyoin1]

CC @MarekKnapek
I revived your PR, I hope you dont mind me giving my self co-author

---

Changes since #23958:

• We now use a custom ifunc resolver, as the sha target seems to be silently ignored at best by all compilers

[MarekKnapek]

Yes, no problem, you have done lot of work on this and helped me much, I thank you for this. Now, towards AES... should be easier than this.

[DanShaders]

We can hide __cpuid_count in some AK::cpu_supports(Capability::SHA) which would also cache the result. (This will be similar to how __builtin_cpu_supports works)

[Hendiadyoin1]

Well copilot said the same, but sadly we dont have that API yet

[DanShaders]

It's never late to introduce a new helper!

[MarekKnapek]

The problem is with clang only, GCC 11.1 supports both the function attribute and the query.

[DanShaders]

Nope, we later figured on Discord that neither Clang nor GCC did the correct thing. Compare assembly for use_f and use_transform_impl here.

[MarekKnapek]

Sorry, I was wrong. GCC does support the __builtin_cpu_supports("sha") test since 11.1 but clang does not, not even the latest one version 18. https://godbolt.org/z/cP7WGYqGq Both compilers do not support the automatic dispatch thing (Function Multiversioning).

[MarekKnapek]

Maybe add test whether the CPUID has at least 7 leaves before reading from the 7th leaf. This is done by setting the eax register to zero and invoking the cpuid instruction, or, from the C language, by calling the __get_cpuid_max(0, NULL) function provided by the <cpuid.h> header. https://godbolt.org/z/v6q89rqhn

[Hendiadyoin1]

Maybe add test whether the CPUID has at least 7 leaves before reading from the 7th leaf. This is done by setting the eax register to zero and invoking the cpuid instruction, or, from the C language, by calling the __get_cpuid_max(0, NULL) function provided by the <cpuid.h> header. https://godbolt.org/z/v6q89rqhn

For now I'll elide that, as memset also avoids that, and I am pretty sure that cpus without the Extentions leaf are missing other features we rely on

[Hendiadyoin1]

Before (Clang):

Benchmarking sha1...
Running benchmark for sha1 with size 16 for ~3000ms...3001ms, 8391481 ops, 14.3 MiB/s
Running benchmark for sha1 with size 1024 for ~3000ms...3001ms, 907621 ops, 240.3 MiB/s
Running benchmark for sha1 with size 16384 for ~3000ms...3001ms, 62750 ops, 324.2 MiB/s
Running benchmark for sha1 with size 262144 for ~3000ms...3001ms, 3931 ops, 327.1 MiB/s
Running benchmark for sha1 with size 1048576 for ~3000ms...3002ms, 960 ops, 319.4 MiB/s
Running benchmark for sha1 with size 16777216 for ~3000ms...3036ms, 62 ops, 326.1 MiB/s
Algorithm            Size       Min us/op  Max us/op  Avg us/op  Throughput
sha1                 16 B       1          112        1          14.3 MiB  /s
sha1                 1.0 KiB    4          57         4          240.3 MiB /s
sha1                 16.0 KiB   46         121        48         324.2 MiB /s
sha1                 256.0 KiB  732        1029       763        327.1 MiB /s
sha1                 1.0 MiB    3003       5511       3126       319.4 MiB /s
sha1                 16.0 MiB   48587      49801      48965      326.1 MiB /s

After:

Benchmarking sha1...
Running benchmark for sha1 with size 16 for ~3000ms...3001ms, 14939406 ops, 14.3 MiB/s
Running benchmark for sha1 with size 1024 for ~3000ms...3001ms, 4136306 ops, 965.1 MiB/s
Running benchmark for sha1 with size 16384 for ~3000ms...3001ms, 336116 ops, 1.6 GiB/s
Running benchmark for sha1 with size 262144 for ~3000ms...3001ms, 21397 ops, 1.7 GiB/s
Running benchmark for sha1 with size 1048576 for ~3000ms...3001ms, 5331 ops, 1.7 GiB/s
Running benchmark for sha1 with size 16777216 for ~3000ms...3003ms, 331 ops, 1.7 GiB/s
Algorithm            Size       Min us/op  Max us/op  Avg us/op  Throughput
sha1                 16 B       1          62         1          14.3 MiB  /s
sha1                 1.0 KiB    1          121        1          965.1 MiB /s
sha1                 16.0 KiB   9          104        9          1.6 GiB   /s
sha1                 256.0 KiB  135        310        140        1.7 GiB   /s
sha1                 1.0 MiB    536        759        563        1.7 GiB   /s
sha1                 16.0 MiB   8899       9256       9070       1.7 GiB   /s

So a 5.3x speedup for sha1 on my end

[DanShaders]

Hope I'm not too annoying with asking to use C++ standard syntax for attributes wherever possible.

[DanShaders]

Should we move these into tests?

[Hendiadyoin1]

IMO static_asserts should stay in the header, not sure if we have many of those in the test files
for AK/Concepts.h maybe?

[DanShaders]

There are countless instances of static_assert in Tests/AK, while the only thing that is being tested inline in a header in AK is explode_byte.

[Hendiadyoin1]

I'll leave them here for now
(Side note the Kernel likes inline static_asserts)

[DanShaders]

How about (untested)

template<typename ElementType, size_t n, auto function>
void test(ReadonlySpan<u64> values, ReadonlySpan<u64> expected)
{
    VERIFY(values.size() == n);
    VERIFY(expected.size() == n);
    using Type = ElementType __attribute__((vector_size(n * sizeof(ElementType))));
    auto v = AK::SIMD::load_unaligned<Type>(&values[0]);
    v = function(v);
    ElementType result[n];
    AK::SIMD::store_unaligned(result, v);
    for (size_t i = 0; i < n; ++i)
        EXPECT_EQ(result[i], expected[i]);
}

and expressing all 1000 lines of tests with a nice and short array of structs?

[Hendiadyoin1]

Well this wont work on GCC, but will look into it

[nico]

@gmta, do the first few SIMD commits look good to you?

(I think this is fine for merging, but you know the SIMD bits much better.)