Macro incant 

incant!() { /* proc-macro */ }

Dispatch to platform-specific SIMD variants.

Entry Point Mode (no token yet)

Summons tokens and dispatches to the best available variant:

pub fn public_api(data: &[f32]) -> f32 {
    incant!(dot(data))
}

Expands to runtime feature detection + dispatch to dot_v3, dot_v4, dot_neon, dot_wasm128, or dot_scalar.

Explicit Tiers

Specify which tiers to dispatch to:

// Only dispatch to v1, v3, neon, and scalar
pub fn api(data: &[f32]) -> f32 {
    incant!(process(data), [v1, v3, neon, scalar])
}

Always include scalar in explicit tier lists — incant! always emits a fn_scalar() call as the final fallback, and listing it documents this dependency. Currently auto-appended if omitted; will become a compile error in v1.0. Unknown tier names cause a compile error. Tiers are automatically sorted into correct dispatch order (highest priority first).

Known tiers: v1, v2, v3, v4, v4x, neon, neon_aes, neon_sha3, neon_crc, wasm128, wasm128_relaxed, scalar.

Passthrough Mode (already have token)

Uses compile-time dispatch via IntoConcreteToken:

#[arcane]
fn outer(token: X64V3Token, data: &[f32]) -> f32 {
    incant!(inner(data) with token)
}

Also supports explicit tiers:

fn inner<T: IntoConcreteToken>(token: T, data: &[f32]) -> f32 {
    incant!(process(data) with token, [v3, neon, scalar])
}

The compiler monomorphizes the dispatch, eliminating non-matching branches.

Variant Naming

Functions must have suffixed variants matching the selected tiers:

• _v1 for X64V1Token
• _v2 for X64V2Token
• _v3 for X64V3Token
• _v4 for X64V4Token (requires avx512 feature)
• _v4x for X64V4xToken (requires avx512 feature)
• _neon for NeonToken
• _neon_aes for NeonAesToken
• _neon_sha3 for NeonSha3Token
• _neon_crc for NeonCrcToken
• _wasm128 for Wasm128Token
• _scalar for ScalarToken