Skip to content

Add #[simd] macro - #347

Open
Shnatsel wants to merge 7 commits into
linebender:mainfrom
Shnatsel:simd-macro
Open

Add #[simd] macro#347
Shnatsel wants to merge 7 commits into
linebender:mainfrom
Shnatsel:simd-macro

Conversation

@Shnatsel

@Shnatsel Shnatsel commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

My attempt at #338

I am not well-versed in proc macros. While the design of what the macro should expand into is mine, the implementation of the macro and thinking through various edge cases and handling them was largely delegated to Codex (GPT-5.6 Sol Ultra).

Codex summary of the changes

Implemented the standalone #[simd] proc macro.

Key pieces:

  • Added publishable fearless_simd_macros 0.1.0 with Syn 3.0.4 and no core dependency: implementation, documentation.
  • Exact tail expansion to token.vectorize(#[inline(always)] || { ... }), with no generated outer inline attribute.
  • Implemented token selection, wildcard hygiene, attribute preservation, supported function forms, and all specified diagnostics.
  • Updated generated vectorize helpers and removed the stale outlined-boundary documentation.
  • Added behavioral, no-std, and Trybuild coverage: behavioral tests, UI tests.
  • Updated CI, READMEs, changelog, MSRV checks, and release-order documentation.
  • Core’s normal dependency tree remains unchanged.

Verification passed:

  • Full workspace suite on Rust 1.89: 10,304 main harness tests passed, 115 ignored.
  • Clippy and rustdoc with -D warnings.
  • 2 Trybuild pass cases and 15 expected failures.
  • x86_64-unknown-none no-std build.
  • Wasm SIMD/fallback and AArch64 NEON/fallback runtime tests.
  • Generator and cargo-rdme consistency.
  • Offline macro package assembly and verification.
  • Formatting and git diff --check.

Existing unrelated untracked workspace files were left untouched.

Before implementing the macro I investigated vectorize() and found that it already gets inlined most of the time anyway. It doesn't work well as an inlining barrier, since the function that isn't annotated #[inline] is trival enough for the optimizer to always inline it anyway, even with a large closure body. So I reverted a separate vectorize_inline() which is recorded in commit history, and inlining can instead be controlled with annotation on the function calling vectorize(); the docs on it already show that usage in the example, the doc comment on vectorize() can probably be improved.

The proc macro crate is separate from fearless_simd so it doesn't fall under the v1.0 guarantees. I expect to publish it in lockstep with v1.0, although we might ship pre-releases just to make sure it all works. The README points to git but should work with most versions no problem, just wouldn't have as much inlining annotations in vectorize().

…h the documented use case for vectorize(). Does not affect usage in dispatch!() which dispatches from non-target-feature context. The function itself was already trivial and under -O3 the optimizer would recognize it as trivial and inline it anyway, so adding a function boundary there didn't really work as intended, except under -Os.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant