Safe SIMD In Rust, Even On The Inside

TL;DR

Buying for a business?Offer from Amazon

Get business pricing on monitors, keyboards and dev gear

• Business-only prices and quantity discounts
• Tax-exempt purchasing
• Multiple users, one account, clear invoices

Create a free Business account →Free to register

As an affiliate, we earn on qualifying purchases.Hide

Sergey “Shnatsel” Davidoff has described a way to wrap Rust SIMD intrinsics in a safe interface, using CPU-feature tokens and a macro to contain the unsafe operation. The approach addresses safety inside SIMD abstractions, but the supplied report cuts off before explaining its proposed use of generics or providing adoption and review details.

Rust developer Sergey “Shnatsel” Davidoff has outlined a method for wrapping SIMD intrinsics in a safe programming interface, addressing unsafe code that can remain hidden inside higher-level vector abstractions. The technique uses runtime-checked CPU-feature tokens and a macro to confine an unsafe call to a shared implementation, rather than requiring users to mark each intrinsic call unsafe.

SIMD instructions let processors perform operations on multiple data values at once, but the available instruction sets vary by processor. Davidoff says that calling an intrinsic for a feature the current CPU does not support is illegal, which has traditionally required Rust code to use unsafe blocks around those calls. Higher-level abstractions can select implementations for different architectures and CPUs, but, according to his report, their internal implementations may still contain substantial unsafe code.

The report points to a change in Rust 1.87: the compiler began tracking the instruction-set requirements of functions marked with #[target_feature]. That lets a function use an intrinsic matching its declared feature without wrapping that intrinsic itself in an unsafe block. However, Davidoff notes that calling the feature-specific function still requires an unsafe call, so this change alone does not provide a fully safe interface.

His proposed mechanism checks for a feature such as AVX2 at runtime and, if supported, returns a zero-sized token whose private field prevents callers from creating it directly. A function requiring that token can then be wrapped by a macro that places the call to its #[target_feature] implementation inside one unsafe block. Davidoff says the compiler rejects intrinsics that do not match the function’s declared target feature. In his account, this concentrates the safety argument in the macro instead of repeating unsafe calls throughout an abstraction.

Containing Unsafe SIMD Calls

The proposal targets a distinction that matters to Rust developers: a library can offer callers a safe interface while still relying on unsafe code internally. If the internal boundary is sound, callers do not have to manage unsafe blocks for every vector operation, and maintainers can focus review on a smaller shared mechanism. Davidoff compares this kind of encapsulation to other familiar Rust APIs that safely abstract unsafe implementation details.

The token is intended to show that a required CPU feature has been checked without adding runtime cost when it is passed around: the report describes it as a zero-sized type. The feature check itself still occurs at runtime, but the design aims to avoid repeating it for each arithmetic operation by checking once and carrying the proof in the type system. The report’s central claim is that this can make SIMD code easier to use and audit without hand-written feature tracking at each call site.

That is a proposed engineering benefit, not evidence in the supplied material of widespread adoption or independently verified performance. The method’s importance depends on whether the macro and token mapping can be implemented soundly and used across the architectures and SIMD abstractions developers need.

Why Intrinsics Need Feature Checks

SIMD code is tied to processor capabilities. Davidoff describes an ordinary runtime check, such as Rust’s is_x86_feature_detected!("avx2"), as a way to establish whether AVX2 is available. A library may also need implementations for other x86 features, ARM, WebAssembly, or targets with no relevant SIMD support. Choosing and dispatching among those implementations is part of the challenge behind a simple expression such as adding two vectors.

Before the compiler change discussed in the report, the feature requirements of intrinsics had to be tracked and matched against the features available at runtime, either manually or through generated code. Rust 1.87 changed part of that arrangement by letting the compiler check requirements declared with #[target_feature]. Davidoff’s method builds on that compiler support, but addresses the remaining unsafe boundary between a feature-specific function and the code calling it.

The Generic Operator Still Unresolved

The supplied report ends as Davidoff turns to the remaining API problem: making ordinary expressions such as a + b work without asking callers to pass a feature token or mark the operation unsafe. It begins to introduce generics as a possible answer, but the source material provided here stops before explaining that design. The full mechanism for selecting implementations, including how it handles CPUs without SIMD, is not established by the supplied text.

The material also does not give an independent audit, benchmark results, a crate or implementation release, or evidence that the approach has been adopted by Rust’s standard library or existing SIMD libraries. Davidoff identifies two possible macro failure modes—mapping a token to the wrong target feature and permitting an unsafe function in a safe context—and says both are straightforward to check. That is his assessment; the supplied material does not include results from an external review.

How the Operator API Fits

The next part of the proposed design would need to explain how generic types or traits allow ordinary operators to dispatch to an implementation that matches the features available, while keeping the operator safe to call on every supported CPU. That explanation is missing from the supplied excerpt, so the final route from a checked token to a general-purpose a + b interface remains unconfirmed here.

Readers evaluating the proposal would also need the complete source, implementation details, and any review or testing results before judging its safety and portability. The report’s immediate contribution, as provided, is the token-and-macro technique for containing a feature-specific unsafe call; broader adoption and the completed operator design remain open.

Key Questions

What is the proposed Rust SIMD safety method?

Davidoff describes using a runtime-checked CPU-feature token with a macro that contains the unsafe call to a function marked with #[target_feature]. The aim is to give callers a safe interface to the SIMD operation.

Does Rust 1.87 remove all unsafe code from SIMD?

No. According to Davidoff, Rust 1.87 lets the compiler track feature requirements declared by #[target_feature], but calling a feature-specific function still needs an unsafe boundary. His macro is intended to encapsulate that boundary.

What does the AVX2 token prove?

In the described design, the token can only be obtained after an AVX2 runtime check succeeds. Its private field is meant to prevent callers from manufacturing the proof themselves, and its zero-sized form is described as having no runtime storage cost.

Does the report explain how safe vector addition works?

Not in the supplied material. It begins discussing generics as a route to a safe a + b interface, but ends before showing how that design works.

Has the approach been independently verified or widely adopted?

The supplied source does not report an independent audit, benchmark results, a release, or broad adoption. Those points remain unconfirmed in the material provided.

Source: hn