Better codegen for CPU feature detection

Vorpal · January 7, 2026, 7:41am

No? On Linux with musl libc (as opposed to glibc) this works perfectly fine. So you are going to have to explain your point of view here.

Again, musl doesn't support IFUNCs (neither when statically nor when dynamically linked), and that is an intentional design choice by them.

RalfJung · January 9, 2026, 1:15pm

FWIW a data race is UB even if both writes write the same data.

PyPylia · January 11, 2026, 2:37pm

Is there any update on any of this getting implemented? Even something as simple as allowing users to query multiple features at once to prevent multiple redundant reads.

It's a bit annoying that this feature is still so suboptimal to use, which just directs users to other libraries (creating the xkcd 927 problem), especially since you'd expect features of the Rust standard library to be the best overall implementation of any given feature.

pitaj · January 11, 2026, 6:08pm

An ACP was accepted

github.com/rust-lang/libs-team

ACP: efficient runtime checking of multiple target features

opened 10:15AM - 09 May 25 UTC

folkertdev

T-libs-api api-change-proposal ACP-accepted

# Proposal ## Problem statement Currently, checking for whether two target fea…tures are enabled is inefficient. In zlib-rs we see a 3% slowdown in one test case from checking for an additional target feature. Performing a runtime check for 2 target features requires roughly double the number of instructions versus checking for just one feature. ## Motivating examples or use cases In zlib-rs, we want to check for both the `avx2` and `bmi2` features, but that check is slower than just checking for `avx2`. Looking at just the happy path (where the features are already cached and both are available): https://godbolt.org/z/f935sP6dr ```rust // using `pclmulqdq` here because avx2 and bmi2 use the same integer constant pub fn foo() -> bool { std::is_x86_feature_detected!("pclmulqdq") } pub fn bar() -> bool { std::is_x86_feature_detected!("avx2") && std::is_x86_feature_detected!("pclmulqdq") } ``` ```asm example::foo::h4a487a8c8dbb996a: mov rax, qword ptr [rip + std_detect::detect::cache::CACHE::h6b648acf387db542@GOTPCREL] mov rax, qword ptr [rax] test rax, rax je .LBB0_1 and eax, 2 xor ecx, ecx or rax, rcx setne al ret example::bar::h1992ebebbee721d0: push rbx mov rbx, qword ptr [rip + std_detect::detect::cache::CACHE::h6b648acf387db542@GOTPCREL] mov rax, qword ptr [rbx] test rax, rax je .LBB1_1 and eax, 32768 xor ecx, ecx or rax, rcx je .LBB1_3 .LBB1_4: mov rax, qword ptr [rbx] test rax, rax je .LBB1_5 .LBB1_6: and eax, 2 xor ecx, ecx or rax, rcx setne al pop rbx ret ``` So checking for 2 features roughly doubles the number of instructions, and performs 2 (atomic) loads. This all makes sense, given that the cache is stored in an atomic, so the read value cannot be reused, and the expansion looks like this: ```rust pub fn bar() -> bool { (false || ::std_detect::detect::__is_feature_detected::avx2()) && (false || ::std_detect::detect::__is_feature_detected::pclmulqdq()) } ``` ## Solution sketch I'd like the macro to expand to something like this instead, where `__is_feature_detected()` returns a bitmap of enabled features: ```rust pub fn bar() -> bool { false || { let mask = ::std_detect::detect::AVX2 | ::std_detect::detect::PCLMULQDQ; ::std_detect::detect::__is_feature_detected() & mask == mask } } ``` For that to work, a single call to a `is_*_feature_detected` macro must be able to accept multiple target features. I can see two ways to do that: 1. `is_x86_feature_detected("avx2", "bmi")` 2. `is_x86_feature_detected("avx2,bmi")` Option 2 has precedent in e.g. `#[target_feature(enable = "avx2,bmi2")]`, but option 1 can (I believe) be implemented with `macro_rules!` and also works better with e.g. `#[cfg(...)]`. I personally prefer option 1. ## Alternatives There is a workaround: ```rust #[inline(always)] pub fn is_enabled_avx2_and_bmi2() -> bool { #[cfg(any(target_arch = "x86_64", target_arch = "x86"))] #[cfg(feature = "std")] { use std::sync::atomic::{AtomicU8, Ordering}; static CACHE: AtomicU8 = AtomicU8::new(2); return match CACHE.load(Ordering::Relaxed) { 0 => false, 1 => true, _ => { let detected = std::is_x86_feature_detected!("avx2") && std::is_x86_feature_detected!("bmi2"); CACHE.store(u8::from(detected), Ordering::Relaxed); detected } }; } false } ``` ## Links and related work - https://github.com/rust-lang/stdarch/issues/348 ## What happens now? This issue contains an API change proposal (or ACP) and is part of the libs-api team [feature lifecycle]. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months. [feature lifecycle]: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html ## Possible responses The libs team may respond in various different ways. First, the team will consider the *problem* (this doesn't require any concrete solution or alternatives to have been proposed): - We think this problem seems worth solving, and the standard library might be the right place to solve it. - We think that this probably doesn't belong in the standard library. Second, if there's a concrete solution: - We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.) - We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

bascule · January 12, 2026, 3:13am

It's different in a couple different ways:

is_x86_feature_detected! caches all of CPUID, then extracts the feature you ask for from the cache.

cpufeatures queries for a set of features, then stores if the combination you specify is present as an atomic. It should address at least one of the problems described, which was codegen for an && chain of features, but also generally the codegen should be more efficient since it does the check for the presence of the combination of features AOT, whereas is_x86_feature_detected! needs to extract it out of the cached CPUID.

Topic		Replies	Views
Pre-RFC: target-feature detection in libcore language design	29	1787	October 12, 2019
Pre-RFC: contextual target feature detection libs	16	862	September 10, 2023
Pre-RFC: stabilization of target_feature compiler	130	11598	March 25, 2019
Getting explicit SIMD on stable Rust	336	44835	March 25, 2019
Check if target features are available at start compiler	19	1716	July 21, 2024

Better codegen for CPU feature detection

Related topics