vicrodh
3d42214775
Expand the .cargo/config.toml comment to reference both reports of
the SIGILL-at-launch bug: issue #353 (Sandy Bridge on Linux) and
discussion #343 (2012 MacBookPro9,1 / Ivy Bridge on macOS). The
macOS Intel case was diagnosed independently by @afonsojramos, who
opened PR #354 with the same fix landed earlier in b54574a7.
Also codify the forward-looking note afonsojramos suggested in that
PR: if a future hot loop needs AVX2/BMI2, the correct pattern is
per-function #[target_feature] with runtime dispatch (what the `aes`
crate already does via cpufeatures), not a global target-cpu bump
that silently breaks older hardware. This way the rationale is in
the file the next time someone is tempted to raise the baseline.
No code change, comment-only.
cc
43 lines
2.2 KiB
TOML
43 lines
2.2 KiB
TOML
# Enable CPU intrinsics for AES-NI + SSSE3 on x86_64 targets only.
|
|
#
|
|
# The qbz-cmaf crate does AES-128-CTR decrypt on every offline-cached
|
|
# audio frame. Without AES-NI the decrypt falls back to a software
|
|
# implementation that hits ~10 MB/s on a modern CPU; with AES-NI it
|
|
# clears 400+ MB/s. For HiRes (200 MB+ tracks) this is the difference
|
|
# between a 20-second gap and a sub-second one.
|
|
#
|
|
# What we need is ONLY the AES-NI instruction set compiled in. The
|
|
# `aes` crate uses `cpufeatures::new!` to do a runtime CPUID check
|
|
# before dispatching to the hardware path, so as long as the AES-NI
|
|
# code is present in the binary, CPUs without AES-NI fall back to the
|
|
# software implementation gracefully — no crash, just slower decrypt.
|
|
#
|
|
# `target-feature=+aes,+ssse3` is what enables that compile-in.
|
|
# SSSE3 has been in every x86_64 CPU since 2006 (Core 2).
|
|
#
|
|
# We deliberately do NOT set `target-cpu=x86-64-v3` (Haswell baseline,
|
|
# 2013). v3 includes AVX2/BMI2/FMA/LZCNT/MOVBE and LLVM will freely
|
|
# emit those instructions anywhere in the binary — including the
|
|
# startup path, long before CMAF runs. On pre-Haswell CPUs (Sandy
|
|
# Bridge 2011, Ivy Bridge 2012, AMD Bulldozer/Piledriver) the process
|
|
# dies with SIGILL at launch. See issue #353 (Linux, Sandy Bridge) and
|
|
# discussion #343 (macOS, 2012 MacBookPro9,1 / Ivy Bridge). Raising
|
|
# the baseline gave no CMAF speedup — the perf win came entirely from
|
|
# `+aes` — so we keep the AES-NI path and drop the incompatible
|
|
# baseline.
|
|
#
|
|
# If a future hot loop ever warrants AVX2/BMI2, the correct pattern is
|
|
# per-function `#[target_feature]` with runtime dispatch (as the `aes`
|
|
# crate already does via `cpufeatures`), NOT a global microarch bump
|
|
# that silently breaks older hardware.
|
|
#
|
|
# IMPORTANT: these flags MUST be scoped to x86_64 targets. Using
|
|
# `[build] rustflags = ...` applies them to every target, which on
|
|
# aarch64-apple-darwin (and any other ARM target) corrupts the CPU
|
|
# feature inference inside the `ring` crate and fails the build with
|
|
# `assertion failed: CAPS_STATIC == MIN_STATIC_FEATURES`. ARM targets
|
|
# get their own AES/crypto extensions automatically via `aes` crate's
|
|
# armv8 path — we don't need to force anything there.
|
|
[target.'cfg(target_arch = "x86_64")']
|
|
rustflags = ["-C", "target-feature=+aes,+ssse3"]
|