Description
As of nightly-2026-08-21 (rustc 1.100), calls to LLVM intrinsics resolve to their own InstanceKind::LlvmIntrinsic. rustc creates this instance kind for any DefKind::Fn whose symbol name starts with llvm. — in practice the extern "unadjusted" declarations in stdarch/core_arch (SSE, AVX, NEON, and friends):
// rustc_ty_utils/src/instance.rs
} else if tcx.def_kind(def_id) == DefKind::Fn
&& let Some(name) = tcx.codegen_fn_attrs(def_id).symbol_name
&& name.as_str().starts_with("llvm.")
{
ty::InstanceKind::LlvmIntrinsic(def_id)
}
Like InstanceKind::Intrinsic and InstanceKind::Virtual, these have no callable MIR — codegen is expected to handle them in the caller. rustc additionally refuses to compute a FnAbi for them; fn_abi_adjust_for_abi asserts:
assertion `left != right` failed: fn_abi_of_instance should not be called on LLVM intrinsics
Kani has no model for LLVM intrinsics, and since it cannot obtain a FnAbi it cannot even codegen the call's arguments. So codegen_funcall reports such a call as an unsupported construct:
call to LLVM intrinsic `llvm.…` is not currently supported by Kani
This is an UnsupportedConstruct check at the call site, so it only fails verification if the call is actually reachable.
Prior behaviour
Before 1.100 these were foreign items (InstanceKind::Item with is_foreign_item()), so they went through Kani's FFI shim path and produced an equivalent call to foreign "Unadjusted" function … unsupported-construct check. The behaviour is therefore unchanged in substance — only the message and the code path differ.
What full support would require
Modelling the individual LLVM intrinsics that matter, most likely the SIMD ones, similar to how Kani already models #[rustc_intrinsic] intrinsics in codegen/intrinsic.rs. Verifying code that reaches a platform intrinsic is unsupported until then.
Reproducer
Any harness that reaches an extern "unadjusted" llvm.* declaration, e.g. via core::arch SIMD.
Description
As of
nightly-2026-08-21(rustc 1.100), calls to LLVM intrinsics resolve to their ownInstanceKind::LlvmIntrinsic. rustc creates this instance kind for anyDefKind::Fnwhose symbol name starts withllvm.— in practice theextern "unadjusted"declarations instdarch/core_arch(SSE, AVX, NEON, and friends):Like
InstanceKind::IntrinsicandInstanceKind::Virtual, these have no callable MIR — codegen is expected to handle them in the caller. rustc additionally refuses to compute aFnAbifor them;fn_abi_adjust_for_abiasserts:Kani has no model for LLVM intrinsics, and since it cannot obtain a
FnAbiit cannot even codegen the call's arguments. Socodegen_funcallreports such a call as an unsupported construct:This is an
UnsupportedConstructcheck at the call site, so it only fails verification if the call is actually reachable.Prior behaviour
Before 1.100 these were foreign items (
InstanceKind::Itemwithis_foreign_item()), so they went through Kani's FFI shim path and produced an equivalentcall to foreign "Unadjusted" function …unsupported-construct check. The behaviour is therefore unchanged in substance — only the message and the code path differ.What full support would require
Modelling the individual LLVM intrinsics that matter, most likely the SIMD ones, similar to how Kani already models
#[rustc_intrinsic]intrinsics incodegen/intrinsic.rs. Verifying code that reaches a platform intrinsic is unsupported until then.Reproducer
Any harness that reaches an
extern "unadjusted"llvm.*declaration, e.g. viacore::archSIMD.