stdarch NEON 未实现指令清单解析arm 与 aarch64 内建函数的缺失现状与实现边界【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust本文基于 Rust 标准库 stdarch 项目在 library/stdarch/crates/core_arch/MISSING.md 中维护的缺失指令清单系统梳理 Arm NEON 内建函数在 stdarch 中的三档实现状态——未在 stdarch 实现、未在 LLVM 实现、以及可能触发 LLVM Select 错误——并对照仓库中的生成源码aarch64/neon/generated.rs、arm_shared/neon/generated.rs与规范文件spec/neon/aarch64.spec.yml、spec/neon/arm_shared.spec.yml说明这些指令的语义、所需 target feature、稳定性门控与规避方法帮助读者准确判断内建函数在当前 rustc/LLVM 环境下的可用性。1. MISSING.md 是什么stdarch 的指令缺口台账MISSING.md位于 stdarch 的core_archcrate 目录下与 README.md、missing-x86.md 并列是 stdarch 维护的“未实现指令台账”。其中missing-x86.md记录 x86 指令缺口如 AVX512_FP16、CET_SS 等而本文件专门记录Arm NEONarm32 位与aarch6464 位指令的缺口。该文件把缺失分为三类构成理解 NEON 内建函数实现状态的核心框架类别含义涉及指令族Not implemented on arm这些指令的 stdarch 内建函数在 32 位arm目标上尚未实现部分在 aarch64 已实现vcadd*、vdot*、vcmla*Not implemented in LLVM底层 LLVM 尚未提供对应的 intrinsicstdarch 无法绑定vrnd32x*、vrnd32z*、vrnd64x*、vrnd64z*f64 变体LLVM Select errors may occurstdarch 已提供绑定但代码生成SelectionDAG阶段可能触发 LLVM Select 错误vsudot*、vusdot*值得说明的是MISSING.md 的措辞是“currently not implemented in stdarch”即这是一份动态变化的快照随着 rustc/LLVM 版本迭代清单中的条目会陆续被实现并从文件中移除。因此读者在较新版本中可能看到某些指令已经可用——这正是查阅本文件的意义它定位了历史与现状的交界。2. 类别一arm 上未实现的 NEON 指令vcadd / vdot / vcmla2.1 清单全文vcadd_rot270_f32 vcadd_rot90_f32 vcaddq_rot270_f32 vcaddq_rot90_f32 vdot_s32 vdot_u32 vdotq_s32 vdotq_u32 vdot_lane_s32 vdot_lane_u32 vdotq_lane_s32 vdotq_lane_u32 vcmla_f32 vcmla_lane_f32 vcmla_laneq_f32 vcmla_rot180_f32 vcmla_rot180_lane_f32 vcmla_rot180_laneq_f32 vcmla_rot270_f32 vcmla_rot270_lane_f32 vcmla_rot270_laneq_f32 vcmla_rot90_f32 vcmla_rot90_lane_f32 vcmla_rot90_laneq_f32 vcmlaq_f32 vcmlaq_lane_f32 vcmlaq_laneq_f32 vcmlaq_rot180_f32 vcmlaq_rot180_lane_f32 vcmlaq_rot180_laneq_f32 vcmlaq_rot270_f32 vcmlaq_rot270_lane_f32 vcmlaq_rot270_laneq_f32 vcmlaq_rot90_f32 vcmlaq_rot90_lane_f32 vcmlaq_rot90_laneq_f32这三组指令分别属于三个 Arm 架构扩展vcadd*Floating-point complex add复数加法Complex Add需要neonfcmafeature对应fcadd指令vdot*Dot product arithmetic8 位整数点积需要neondotprodfeature对应sdot/udot指令vcmla*Floating-point complex multiply accumulate复数乘累加Complex MLA需要neonfcmafeature对应fcmla指令。2.2 为什么arm 上未实现源码证据对照仓库源码可以发现这些函数在aarch64 端已经实现而 32 位 arm 端缺失这印证了 MISSING.md 的归类。例如 aarch64/neon/generated.rs 中的vcadd_rot270_f32#[cfg(target_endian little)] #[target_feature(enable neon,fcma)] #[unstable(feature stdarch_neon_fcma, issue 117222)] #[cfg_attr(test, assert_instr(fcadd))] pub fn vcadd_rot270_f32(a: float32x2_t, b: float32x2_t) - float32x2_t { unsafe extern llvm-intrinsic { #[cfg_attr( any(target_arch aarch64, target_arch arm64ec), link_name llvm.aarch64.neon.vcadd.rot270.v2f32 )] fn _vcadd_rot270_f32(a: float32x2_t, b: float32x2_t) - float32x2_t; } unsafe { _vcadd_rot270_f32(a, b) } }同理vdot_s32在 arm_shared/neon/generated.rs 中同时为 arm 与 aarch64 定义了绑定arm 端通过llvm.arm.neon.sdot.v2i32.v8i8aarch64 端通过llvm.aarch64.neon.sdot.v2i32.v8i8但其#[cfg(target_endian little)]/#[cfg(target_endian big)]双分支结构以及#[unstable(feature stdarch_arm_neon_intrinsics, issue 111800)]门控说明 32 位 arm 上的支持仍处于不完整/不稳定状态。vcmlaq_f32同样在 aarch64/neon/generated.rs 有实现而 arm 端缺失。从 spec/neon/aarch64.spec.yml约第 5702–6048 行可以看到vcadd、vcmla各旋转变体rot90/rot180/rot270的规范条目说明代码生成管线stdarch-gen-arm面向 aarch64 生成arm 端的缺口意味着生成模板或验证通道尚未完全覆盖 32 位目标。2.3 对 arm 开发者的实践意义若你的目标是 32 位arm如armv7-unknown-linux-gnueabihf并使用这些内建函数在编译时可能遇到未找到该内建函数或 feature 门控错误。解决路径切换到 aarch64 目标或改用 C 头文件中的等效 intrinsic如arm_neon.h参与 stdarch 实现工作将 aarch64 已实现的模板扩展到 arm通过#[cfg(target_arch aarch64)]在代码层面做平台分支。3. 类别二LLVM 未实现的指令vrnd32/vrnd64 的 f64 变体3.1 清单全文vrnd32x_f64 vrnd32xq_f64 vrnd32z_f64 vrnd32zq_f64 vrnd64x_f64 vrnd64xq_f64 vrnd64z_f64 vrnd64zq_f64这些函数执行浮点向 32/64 位整数取整需要neonfrinttsfeature对应frint32x/frint32z/frint64x/frint64z指令。MISSING.md 将其标注为Not implemented in LLVM意味着上游 LLVM 尚未为 f64 变体提供对应的 intrinsicstdarch 无法建立绑定。3.2 源码佐证f32 已实现、f64 待定仓库中 aarch64/neon/generated.rs 已有vrnd32x_f64的绑定占位#[target_feature(enable neon,frintts)] #[unstable(feature stdarch_neon_ftts, issue 117227)] #[cfg_attr(all(test, not(target_env msvc)), assert_instr(frint32x))] pub fn vrnd32x_f64(a: float64x1_t) - float64x1_t { unsafe extern llvm-intrinsic { #[cfg_attr( any(target_arch aarch64, target_arch arm64ec), link_name llvm.aarch64.frint32x.f64 )] fn _vrnd32x_f64(a: f64) - f64; } unsafe { transmute(_vrnd32x_f64(vget_lane_f64::0(a))) } }注意这里link_name使用llvm.aarch64.frint32x.f64而非llvm.aarch64.neon.*前缀且函数体通过transmute把标量f64结果重新包装为float64x1_t——这是典型的LLVM 只提供标量 intrinsicstdarch 手工封装成向量接口的模式。对比之下同族 f32 变体如 vrnd32z_f32直接绑定llvm.aarch64.neon.frint32z.v2f32向量 intrinsic。这种不对称正是LLVM 尚未实现 f64 向量形式的表现stdarch 只能退而求其次用标量 intrinsic 拼装甚至部分 f64 变体vrnd64*连标量 intrinsic 也未必齐备因此整体仍列在 MISSING.md 中。3.3 实践建议若只使用 f32 变体vrnd32x_f32、vrnd32z_f32等它们在 aarch64 上可以正常使用但需要显式启用neon,frinttsfeature并在 nightly Rust 上开启stdarch_neon_ftts门控若必须使用 f64 变体需要等待上游 LLVM 补齐 intrinsic或先用标量指令如frint32x对应的内联汇编自行封装在stdarch-verify的测试清单tests/arm.rs中可以看到vcadd系列等指令的验证条目可作为判断某指令是否已纳入验证通道的参考。4. 类别三可能触发 LLVM Select 错误的指令vsudot/vusdot4.1 清单全文vsudot_lane_s32 vsudot_laneq_s32 vsudotq_lane_s32 vsudotq_laneq_s32 vusdot_lane_s32 vusdot_laneq_s32 vusdot_s32 vusdotq_lane_s32 vusdotq_laneq_s32 vusdotq_s32v这些是8 位整数混合符号点积signed×unsigned dot product需要neoni8mmfeatureAArch64 上的usdot/sudot指令属于 Armv8.6-A 的 i8mm 扩展。MISSING.md 的分类说明stdarch 已经提供绑定但在某些目标/条件下LLVM 的 Select指令选择阶段可能报错。4.2 源码证据绑定确实存在这些函数在 arm_shared/neon/generated.rs 中已实现例如vusdot_s32第 68389 行起#[cfg(target_endian little)] #[target_feature(enable neon,i8mm)] #[cfg_attr(target_arch arm, target_feature(enable v8))] #[cfg_attr(all(test, target_arch arm), assert_instr(vusdot))] #[cfg_attr( all(test, any(target_arch aarch64, target_arch arm64ec), target_endian little), assert_instr(usdot) )] #[cfg_attr(not(target_arch arm), unstable(feature stdarch_neon_i8mm, issue 117223))] #[cfg_attr(target_arch arm, unstable(feature stdarch_arm_neon_intrinsics, issue 111800))] pub fn vusdot_s32(a: int32x2_t, b: uint8x8_t, c: int8x8_t) - int32x2_t { unsafe extern llvm-intrinsic { #[cfg_attr( any(target_arch aarch64, target_arch arm64ec), link_name llvm.aarch64.neon.usdot.v2i32.v8i8 )] #[cfg_attr(target_arch arm, link_name llvm.arm.neon.usdot.v2i32.v8i8)] fn _vusdot_s32(a: int32x2_t, b: uint8x8_t, c: int8x8_t) - int32x2_t; } unsafe { _vusdot_s32(a, b, c) } }同样vsudot_lane_s32第 65928 行、vusdot_lane_s32第 68299 行等 lane 变体也已在生成代码中提供。这些绑定的存在与 MISSING.md 中Not implemented的表述并不矛盾——本类条目的问题不在 stdarch 侧而在 LLVM 后端的代码生成阶段。4.3 LLVM Select errors may occur 的含义与规避SelectSelectionDAG 指令选择是 LLVM 将目标无关 DAG 映射为具体机器指令的阶段。当 stdarch 为llvm.aarch64.neon.usdot.v2i32.v8i8这类 intrinsic 提供绑定、但目标机器或给定 target-feature 组合下 LLVM 的指令选择表.td 文件未覆盖该 intrinsic 的某种向量类型/条件组合时就会出现 Select 错误通常表现为编译期报错如 Cannot select: intrinsic %llvm.aarch64.neon.usdot...。规避策略优先使用已验证的变体从 spec/neon/arm_shared.spec.yml约第 6166–6244、6993–7045 行可见vusdot/vsudot的 lane 变体通常通过FnCall组合先做vreinterpret再调用基础vusdot/vusdot_s32实现可优先选择这些由已验证基础函数派生的变体显式启用完整 feature 组合确保-C target-featureneon,i8mmaarch64 还需确认目标 CPU 支持 i8mm如 cortex-a510 及更新并考虑同时启用dotprod减少指令选择表缺口的触发概率版本适配这类错误高度依赖 LLVM 版本升级 rustc自带 LLVM或换用不同目标 CPU 后可能消失汇编兜底在目标机器上先用#[cfg(target_arch aarch64)] 内联汇编实现等价逻辑绕过 LLVM intrinsic 选择路径。5. 如何阅读与更新这份清单MISSING.md 服务于三类读者应用开发者编译前先查清单快速判断某个 NEON 内建函数在当前工具链下是否可用避免踩到未实现或Select 错误stdarch 贡献者清单是待办事项列表——Not implemented on arm 条目意味着可以把 aarch64/neon/generated.rs 中已验证的实现扩展成 arm 端绑定并补充 stdarch-verify 测试条目LLVM 开发者Not implemented in LLVM 与 LLVM Select errors 两类条目指向上游工作为frint32x/64x等补齐 f64 向量 intrinsic或修复 i8mm 点积的指令选择表。实现新指令的标准路径可以参考 stdarch-gen-arm 的规范文件spec/neon/aarch64.spec.yml 与 spec/neon/arm_shared.spec.yml在 YAML 规范中声明指令名称、LLVM intrinsic 链接名与FnCall组合方式由代码生成器产出generated.rs再配合assert_instr指令级断言与验证测试确保生成正确。清单条目被实现后即可从 MISSING.md 中移除并在 intrinsic-test 的缺失清单如 missing_arm_common.txt中同步清理。6. 小结MISSING.md 以三行分类浓缩了 stdarch 在 Arm NEON 上的全部实现缺口arm 端缺口vcadd/vdot/vcmla的 32 位支持aarch64 已实现arm 尚未跟进涉及fcma/dotprodfeatureLLVM 端缺口vrnd32/64的 f64 变体上游 intrinsic 缺失涉及frinttsfeaturef32 变体可用作替代代码生成风险vsudot/vusdot的 i8mm 点积绑定已存在但 LLVM Select 阶段可能失败需要验证 feature 组合与 LLVM 版本。对照 aarch64/neon/generated.rs 与 arm_shared/neon/generated.rs 中的实际绑定代码可以确认这些分类与实现状态完全对应。作为动态台账它的内容会随 rustc/LLVM 演进而变化——建议在使用相关内建函数时结合当前工具链版本重新核对清单并以生成源码中的#[target_feature]与#[unstable]门控为准绳。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 stdarch NEON 未实现指令清单解析：arm 与 aarch64 内建函数的缺失现状与实现边界
stdarch NEON 未实现指令清单解析arm 与 aarch64 内建函数的缺失现状与实现边界【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust本文基于 Rust 标准库 stdarch 项目在 library/stdarch/crates/core_arch/MISSING.md 中维护的缺失指令清单系统梳理 Arm NEON 内建函数在 stdarch 中的三档实现状态——未在 stdarch 实现、未在 LLVM 实现、以及可能触发 LLVM Select 错误——并对照仓库中的生成源码aarch64/neon/generated.rs、arm_shared/neon/generated.rs与规范文件spec/neon/aarch64.spec.yml、spec/neon/arm_shared.spec.yml说明这些指令的语义、所需 target feature、稳定性门控与规避方法帮助读者准确判断内建函数在当前 rustc/LLVM 环境下的可用性。1. MISSING.md 是什么stdarch 的指令缺口台账MISSING.md位于 stdarch 的core_archcrate 目录下与 README.md、missing-x86.md 并列是 stdarch 维护的“未实现指令台账”。其中missing-x86.md记录 x86 指令缺口如 AVX512_FP16、CET_SS 等而本文件专门记录Arm NEONarm32 位与aarch6464 位指令的缺口。该文件把缺失分为三类构成理解 NEON 内建函数实现状态的核心框架类别含义涉及指令族Not implemented on arm这些指令的 stdarch 内建函数在 32 位arm目标上尚未实现部分在 aarch64 已实现vcadd*、vdot*、vcmla*Not implemented in LLVM底层 LLVM 尚未提供对应的 intrinsicstdarch 无法绑定vrnd32x*、vrnd32z*、vrnd64x*、vrnd64z*f64 变体LLVM Select errors may occurstdarch 已提供绑定但代码生成SelectionDAG阶段可能触发 LLVM Select 错误vsudot*、vusdot*值得说明的是MISSING.md 的措辞是“currently not implemented in stdarch”即这是一份动态变化的快照随着 rustc/LLVM 版本迭代清单中的条目会陆续被实现并从文件中移除。因此读者在较新版本中可能看到某些指令已经可用——这正是查阅本文件的意义它定位了历史与现状的交界。2. 类别一arm 上未实现的 NEON 指令vcadd / vdot / vcmla2.1 清单全文vcadd_rot270_f32 vcadd_rot90_f32 vcaddq_rot270_f32 vcaddq_rot90_f32 vdot_s32 vdot_u32 vdotq_s32 vdotq_u32 vdot_lane_s32 vdot_lane_u32 vdotq_lane_s32 vdotq_lane_u32 vcmla_f32 vcmla_lane_f32 vcmla_laneq_f32 vcmla_rot180_f32 vcmla_rot180_lane_f32 vcmla_rot180_laneq_f32 vcmla_rot270_f32 vcmla_rot270_lane_f32 vcmla_rot270_laneq_f32 vcmla_rot90_f32 vcmla_rot90_lane_f32 vcmla_rot90_laneq_f32 vcmlaq_f32 vcmlaq_lane_f32 vcmlaq_laneq_f32 vcmlaq_rot180_f32 vcmlaq_rot180_lane_f32 vcmlaq_rot180_laneq_f32 vcmlaq_rot270_f32 vcmlaq_rot270_lane_f32 vcmlaq_rot270_laneq_f32 vcmlaq_rot90_f32 vcmlaq_rot90_lane_f32 vcmlaq_rot90_laneq_f32这三组指令分别属于三个 Arm 架构扩展vcadd*Floating-point complex add复数加法Complex Add需要neonfcmafeature对应fcadd指令vdot*Dot product arithmetic8 位整数点积需要neondotprodfeature对应sdot/udot指令vcmla*Floating-point complex multiply accumulate复数乘累加Complex MLA需要neonfcmafeature对应fcmla指令。2.2 为什么arm 上未实现源码证据对照仓库源码可以发现这些函数在aarch64 端已经实现而 32 位 arm 端缺失这印证了 MISSING.md 的归类。例如 aarch64/neon/generated.rs 中的vcadd_rot270_f32#[cfg(target_endian little)] #[target_feature(enable neon,fcma)] #[unstable(feature stdarch_neon_fcma, issue 117222)] #[cfg_attr(test, assert_instr(fcadd))] pub fn vcadd_rot270_f32(a: float32x2_t, b: float32x2_t) - float32x2_t { unsafe extern llvm-intrinsic { #[cfg_attr( any(target_arch aarch64, target_arch arm64ec), link_name llvm.aarch64.neon.vcadd.rot270.v2f32 )] fn _vcadd_rot270_f32(a: float32x2_t, b: float32x2_t) - float32x2_t; } unsafe { _vcadd_rot270_f32(a, b) } }同理vdot_s32在 arm_shared/neon/generated.rs 中同时为 arm 与 aarch64 定义了绑定arm 端通过llvm.arm.neon.sdot.v2i32.v8i8aarch64 端通过llvm.aarch64.neon.sdot.v2i32.v8i8但其#[cfg(target_endian little)]/#[cfg(target_endian big)]双分支结构以及#[unstable(feature stdarch_arm_neon_intrinsics, issue 111800)]门控说明 32 位 arm 上的支持仍处于不完整/不稳定状态。vcmlaq_f32同样在 aarch64/neon/generated.rs 有实现而 arm 端缺失。从 spec/neon/aarch64.spec.yml约第 5702–6048 行可以看到vcadd、vcmla各旋转变体rot90/rot180/rot270的规范条目说明代码生成管线stdarch-gen-arm面向 aarch64 生成arm 端的缺口意味着生成模板或验证通道尚未完全覆盖 32 位目标。2.3 对 arm 开发者的实践意义若你的目标是 32 位arm如armv7-unknown-linux-gnueabihf并使用这些内建函数在编译时可能遇到未找到该内建函数或 feature 门控错误。解决路径切换到 aarch64 目标或改用 C 头文件中的等效 intrinsic如arm_neon.h参与 stdarch 实现工作将 aarch64 已实现的模板扩展到 arm通过#[cfg(target_arch aarch64)]在代码层面做平台分支。3. 类别二LLVM 未实现的指令vrnd32/vrnd64 的 f64 变体3.1 清单全文vrnd32x_f64 vrnd32xq_f64 vrnd32z_f64 vrnd32zq_f64 vrnd64x_f64 vrnd64xq_f64 vrnd64z_f64 vrnd64zq_f64这些函数执行浮点向 32/64 位整数取整需要neonfrinttsfeature对应frint32x/frint32z/frint64x/frint64z指令。MISSING.md 将其标注为Not implemented in LLVM意味着上游 LLVM 尚未为 f64 变体提供对应的 intrinsicstdarch 无法建立绑定。3.2 源码佐证f32 已实现、f64 待定仓库中 aarch64/neon/generated.rs 已有vrnd32x_f64的绑定占位#[target_feature(enable neon,frintts)] #[unstable(feature stdarch_neon_ftts, issue 117227)] #[cfg_attr(all(test, not(target_env msvc)), assert_instr(frint32x))] pub fn vrnd32x_f64(a: float64x1_t) - float64x1_t { unsafe extern llvm-intrinsic { #[cfg_attr( any(target_arch aarch64, target_arch arm64ec), link_name llvm.aarch64.frint32x.f64 )] fn _vrnd32x_f64(a: f64) - f64; } unsafe { transmute(_vrnd32x_f64(vget_lane_f64::0(a))) } }注意这里link_name使用llvm.aarch64.frint32x.f64而非llvm.aarch64.neon.*前缀且函数体通过transmute把标量f64结果重新包装为float64x1_t——这是典型的LLVM 只提供标量 intrinsicstdarch 手工封装成向量接口的模式。对比之下同族 f32 变体如 vrnd32z_f32直接绑定llvm.aarch64.neon.frint32z.v2f32向量 intrinsic。这种不对称正是LLVM 尚未实现 f64 向量形式的表现stdarch 只能退而求其次用标量 intrinsic 拼装甚至部分 f64 变体vrnd64*连标量 intrinsic 也未必齐备因此整体仍列在 MISSING.md 中。3.3 实践建议若只使用 f32 变体vrnd32x_f32、vrnd32z_f32等它们在 aarch64 上可以正常使用但需要显式启用neon,frinttsfeature并在 nightly Rust 上开启stdarch_neon_ftts门控若必须使用 f64 变体需要等待上游 LLVM 补齐 intrinsic或先用标量指令如frint32x对应的内联汇编自行封装在stdarch-verify的测试清单tests/arm.rs中可以看到vcadd系列等指令的验证条目可作为判断某指令是否已纳入验证通道的参考。4. 类别三可能触发 LLVM Select 错误的指令vsudot/vusdot4.1 清单全文vsudot_lane_s32 vsudot_laneq_s32 vsudotq_lane_s32 vsudotq_laneq_s32 vusdot_lane_s32 vusdot_laneq_s32 vusdot_s32 vusdotq_lane_s32 vusdotq_laneq_s32 vusdotq_s32v这些是8 位整数混合符号点积signed×unsigned dot product需要neoni8mmfeatureAArch64 上的usdot/sudot指令属于 Armv8.6-A 的 i8mm 扩展。MISSING.md 的分类说明stdarch 已经提供绑定但在某些目标/条件下LLVM 的 Select指令选择阶段可能报错。4.2 源码证据绑定确实存在这些函数在 arm_shared/neon/generated.rs 中已实现例如vusdot_s32第 68389 行起#[cfg(target_endian little)] #[target_feature(enable neon,i8mm)] #[cfg_attr(target_arch arm, target_feature(enable v8))] #[cfg_attr(all(test, target_arch arm), assert_instr(vusdot))] #[cfg_attr( all(test, any(target_arch aarch64, target_arch arm64ec), target_endian little), assert_instr(usdot) )] #[cfg_attr(not(target_arch arm), unstable(feature stdarch_neon_i8mm, issue 117223))] #[cfg_attr(target_arch arm, unstable(feature stdarch_arm_neon_intrinsics, issue 111800))] pub fn vusdot_s32(a: int32x2_t, b: uint8x8_t, c: int8x8_t) - int32x2_t { unsafe extern llvm-intrinsic { #[cfg_attr( any(target_arch aarch64, target_arch arm64ec), link_name llvm.aarch64.neon.usdot.v2i32.v8i8 )] #[cfg_attr(target_arch arm, link_name llvm.arm.neon.usdot.v2i32.v8i8)] fn _vusdot_s32(a: int32x2_t, b: uint8x8_t, c: int8x8_t) - int32x2_t; } unsafe { _vusdot_s32(a, b, c) } }同样vsudot_lane_s32第 65928 行、vusdot_lane_s32第 68299 行等 lane 变体也已在生成代码中提供。这些绑定的存在与 MISSING.md 中Not implemented的表述并不矛盾——本类条目的问题不在 stdarch 侧而在 LLVM 后端的代码生成阶段。4.3 LLVM Select errors may occur 的含义与规避SelectSelectionDAG 指令选择是 LLVM 将目标无关 DAG 映射为具体机器指令的阶段。当 stdarch 为llvm.aarch64.neon.usdot.v2i32.v8i8这类 intrinsic 提供绑定、但目标机器或给定 target-feature 组合下 LLVM 的指令选择表.td 文件未覆盖该 intrinsic 的某种向量类型/条件组合时就会出现 Select 错误通常表现为编译期报错如 Cannot select: intrinsic %llvm.aarch64.neon.usdot...。规避策略优先使用已验证的变体从 spec/neon/arm_shared.spec.yml约第 6166–6244、6993–7045 行可见vusdot/vsudot的 lane 变体通常通过FnCall组合先做vreinterpret再调用基础vusdot/vusdot_s32实现可优先选择这些由已验证基础函数派生的变体显式启用完整 feature 组合确保-C target-featureneon,i8mmaarch64 还需确认目标 CPU 支持 i8mm如 cortex-a510 及更新并考虑同时启用dotprod减少指令选择表缺口的触发概率版本适配这类错误高度依赖 LLVM 版本升级 rustc自带 LLVM或换用不同目标 CPU 后可能消失汇编兜底在目标机器上先用#[cfg(target_arch aarch64)] 内联汇编实现等价逻辑绕过 LLVM intrinsic 选择路径。5. 如何阅读与更新这份清单MISSING.md 服务于三类读者应用开发者编译前先查清单快速判断某个 NEON 内建函数在当前工具链下是否可用避免踩到未实现或Select 错误stdarch 贡献者清单是待办事项列表——Not implemented on arm 条目意味着可以把 aarch64/neon/generated.rs 中已验证的实现扩展成 arm 端绑定并补充 stdarch-verify 测试条目LLVM 开发者Not implemented in LLVM 与 LLVM Select errors 两类条目指向上游工作为frint32x/64x等补齐 f64 向量 intrinsic或修复 i8mm 点积的指令选择表。实现新指令的标准路径可以参考 stdarch-gen-arm 的规范文件spec/neon/aarch64.spec.yml 与 spec/neon/arm_shared.spec.yml在 YAML 规范中声明指令名称、LLVM intrinsic 链接名与FnCall组合方式由代码生成器产出generated.rs再配合assert_instr指令级断言与验证测试确保生成正确。清单条目被实现后即可从 MISSING.md 中移除并在 intrinsic-test 的缺失清单如 missing_arm_common.txt中同步清理。6. 小结MISSING.md 以三行分类浓缩了 stdarch 在 Arm NEON 上的全部实现缺口arm 端缺口vcadd/vdot/vcmla的 32 位支持aarch64 已实现arm 尚未跟进涉及fcma/dotprodfeatureLLVM 端缺口vrnd32/64的 f64 变体上游 intrinsic 缺失涉及frinttsfeaturef32 变体可用作替代代码生成风险vsudot/vusdot的 i8mm 点积绑定已存在但 LLVM Select 阶段可能失败需要验证 feature 组合与 LLVM 版本。对照 aarch64/neon/generated.rs 与 arm_shared/neon/generated.rs 中的实际绑定代码可以确认这些分类与实现状态完全对应。作为动态台账它的内容会随 rustc/LLVM 演进而变化——建议在使用相关内建函数时结合当前工具链版本重新核对清单并以生成源码中的#[target_feature]与#[unstable]门控为准绳。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考