| Age | Commit message (Collapse) | Author |
|
The SSE2 patch introduced xmm10 as a temporary register for one of the
rotations, but xmm6-xmm15 are callee-save registers on Windows, and
SSE4.1 was only saving the registers it used. The minimal fix is to use
one of the saved registers instead of xmm10.
See https://github.com/BLAKE3-team/BLAKE3/issues/206.
|
|
|
|
|
|
|
|
|
|
|
|
I'm not sure how to build for Apple Silicon from a Linux host, but it
seems to work as-is from an x86_64 macOS host. Alas, GitHub doesn't yet
provide Apple Silicon hosts to run these binaries, and Cross doesn't yet
support virtualizing them either.
|
|
Changes since 1.0.0:
- The NEON implementation is now enabled by default on AArch64 targets.
Previously it was disabled without the "neon" Cargo feature in Rust or
the "BLAKE3_USE_NEON=1" preprocessor flag in C. This is still the case
on ARM targets other than AArch64, because of the lack of dynamic CPU
feature detection on ARM. Contributed by @rsdy.
- The previous change leads to some build incompatibilities,
particularly in C. If you build the C implementation for AArch64
targets, you now need to include blake3_neon.c, or else you'll get a
linker error like "undefined reference to `blake3_hash_many_neon'". If
you don't want the NEON implementation, you need to explicitly set
"BLAKE3_USE_NEON=0". On the Rust side, AArch64 targets now require the
C toolchain by default. build.rs includes workarounds for missing or
very old C compilers for x86, but it doesn't currently include such
workarounds for AArch64. If we hear about build breaks related to
this, we can add more workarounds as appropriate.
- C-specific Git tags ("c-0.3.7" etc.) have been removed, and all the
projects in this repo (Rust "blake3", Rust "b3sum", and the C
implementation) will continue to be versioned in lockstep for the
foreseeable future.
|
|
|
|
|
|
Improve compile-time target detection for NEON
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See:
https://github.com/BLAKE3-team/BLAKE3/issues/94
https://github.com/BLAKE3-team/BLAKE3/issues/183
https://github.com/BLAKE3-team/BLAKE3/issues/189
|
|
|
|
|
|
Changes since 0.3.8:
- Add Hash::from_hex() and implement FromStr for Hash.
- Implement Display for Hash, equivalent to Hash::to_hex().
- Implement PartialEq<[u8]> for Hash, using constant_time_eq.
- Change derive_key() to return a 32-byte array. As with hash() and
keyed_hash(), callers who want a non-default output length can use
Hasher::finalize_xof().
- Replace Hasher::update_with_join() with Hasher::update_rayon(). The
former was excessively generic, and the Join trait leaked
implementation details. As part of this change, the Join trait is no
longer public.
- Upgraded arrayvec to 0.7.0, which uses const generics. This bumps the
minimum supported Rust compiler version to 1.51.
- Gate the digest and crypto-mac trait implementations behind an
unstable feature, "traits-preview". As part of this change upgrade
crypto-mac to 0.11.0.
|
|
|
|
This version uses const generics, which bumps our minimum supported
compiler version to 1.51.
|
|
|
|
Suggested by @joshtriplett at:
https://github.com/BLAKE3-team/BLAKE3/issues/168#issuecomment-829609667
|
|
|
|
|
|
|
|
|
|
These clutter the toplevel API, and their prominence might lead callers
to prefer them as a first resort, which probably isn't a good idea.
Restricting multithreading to `Hasher::update_rayon` feels better,
similar to what we've done with `Hasher::finalize_xof`. (But I think
`update_rayon` is still an improvement over the trait-based interface
that it replaced.)
|
|
This approach was suggested by @tarcieri at
https://github.com/BLAKE3-team/BLAKE3/pull/157.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Visual Studio <= 2015 does not support AVX-512 either way;
- Visual Studio 2017 does not tolerate vmovd with 64-bit operands;
- Visual Studio 2019 does not care.
|
|
|
|
|
|
Fixes https://github.com/BLAKE3-team/BLAKE3/issues/152.
|
|
Some of the SIMD code is still unformatted, so for now I'm only touching
the files that just have a couple small changes.
|