Tracking Issue for naked_functions_target_rustic_abi

[folkertdev]

The feature gate for the issue is #![feature(naked_functions_target_rustic_abi)].

Because the details of the rust abi are unstable, and a naked function must match its stated ABI, this feature gate keeps naked functions with a rustic abi ("Rust", "rust-cold", "rust-call" and "rust-intrinsic") unstable.

Splitting out this feature was decided on in https://hackmd.io/20YsMoNgRjyxhBm_aVEwQg#Stabilize-naked_functions-rust134213.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement the RFC (cc @rust-lang/XXX -- can anyone write up mentoring
  instructions?)
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

XXX --- list all the "unresolved questions" found in the RFC to ensure they are
not forgotten

Implementation history

@rustbot label +A-naked +F-naked_functions

[folkertdev]

An interesting motivating example is multiversioning on x86 systems. The fma function in the snippet below forwards to the function stored in FNA_FN. Initially that value is resolve_fma, but after the first call it is updated to either fma_fast or fma_slow based on system capabilities.

https://rust.godbolt.org/z/GaPKzeYez

#![feature(naked_functions_rustic_abi)]
use std::sync::atomic::*;

type FmaFn = unsafe extern "Rust" fn(f32, f32, f32) -> f32;

#[unsafe(link_section = ".data")]
static FMA_FN: AtomicPtr<()> = unsafe { AtomicPtr::new(std::mem::transmute(resolve_fma as FmaFn)) };

#[unsafe(naked)]
pub extern "Rust" fn fma(a: f32, b: f32, c: f32) -> f32 {
    std::arch::naked_asm!("jmp qword ptr [rip + {}]", sym FMA_FN)
}

#[target_feature(enable = "fma")]
fn fma_fast(a: f32, b: f32, c: f32) -> f32 {
    a.mul_add(b, c)
}

fn fma_slow(a: f32, b: f32, c: f32) -> f32 {
    a.mul_add(b, c)
}

#[cold]
fn resolve_fma(a: f32, b: f32, c: f32) -> f32 {
    let f: FmaFn = if is_x86_feature_detected!("fma") {
        fma_fast
    } else {
        fma_slow
    };
    FMA_FN.store(unsafe { std::mem::transmute(f) }, Ordering::Relaxed);
    unsafe { f(a, b, c) }
}

The naked fma function upholds its ABI requirements, because even though the rust ABI is unstable, it just forwards to another extern "Rust" function, and does not itself use any arguments passed in via registers.

The naked function is required to work around a limitation in LLVM, that would add a mov instruction before the jump to perform the arithmetic if just a standard atomic read/call is used llvm/llvm-project#136848.

This came up in #t-libs > significant mul_add perf regression since nightly-2025-03-06