It turns out we cannot use function multi-versioning with "sha" feature
or even just plain ifunc resolvers without preprocessor guards. So,
instead of feeding ifdef-soup monster, we just use static member
function pointer.
Moving the kernel into the SHA1 class makes it possible to not pass
class members as parameters to it. This, however, requires us to
disambiguate different target "clones" of the kernel using some kind
of template.
This also removes `[[gnu::target("sse4.2")]]` from nested functions:
since we don't explicitly use any of the SSE4.2 intrinsics there, the
said target is unneeded. Note that this won't prevent compiler from
choosing SSE4.2 intrinsics as the affected functions are always inlined
into `transform_impl_sha1` that has `[[gnu::target("sse4.2")]]`.
This warning is triggered when one accepts or returns vectors from a
function (that is not marked with [[gnu::target(...)]]) which would have
been otherwise passed in register if the current translation unit had
been compiled with more permissive flags wrt instruction selection (i.
e. if one adds -mavx2 to cmdline). This will never be a problem for us
since we (a) never use different instruction selection options across
ABI boundaries; (b) most of the affected functions are actually
TU-local.
Moreover, even if we somehow properly annotated all of the SIMD helpers,
calling them across ABI (or target) boundaries would still be very
dangerous because of inconsistent and bogus handling of
[[gnu::target(...)]] across compilers. See
https://github.com/llvm/llvm-project/issues/64706 and
https://www.reddit.com/r/cpp/comments/17qowl2/comment/k8j2odi .
Instead of going byte by byte, copy entire blocks at once and only check
if we need to update the state once per block. This pretty much
eliminates `::update()` from profiles and measurably improves
performance for utilities like `sha256sum`.
PVS-Studio flagged this, as memset can be optimized away by the compiler
in some cases. We obviously don't want that to ever happen so make sure
to always use `explicit_bzero(..)` which can't be optimized away.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
Problem:
- `constexpr` functions are additionally decorated with `inline`
keyword. This is redundant since `constexpr` implies `inline`.
Solution:
- Remove redundancies.