AVX基础支持需检查__cpuid(1)返回的ecx第28位（OSXSAVE），该位为1才表明OS支持XSAVE/XRSTOR，AVX指令方可安全执行，否则触发#UD异常。
能直接用 __cpuid 或 __cpuidex 查，但必须查对寄存器位——查错地方会误判 AVX 支持。
怎么用 __cpuid 检查 AVX 基础支持
AVX 是否可用，不看 eax 或 ebx，关键在 ecx 的第 28 位（bit 28）。这一位叫 OSXSAVE，它表示操作系统已启用 XSAVE/XRSTOR 机制——这是 AVX 指令能安全执行的前提。即使 CPU 硬件支持 AVX，若 OSXSAVE == 0，用 AVX 指令会触发 #UD 异常。
实操步骤：
- 先调用
__cpuid(1, eax, ebx, ecx, edx)（leaf=1是标准功能检测） - 检查
ecx & (1 是否为真 → 确认 OS 已开启 XSAVE 支持 - 再检查
edx & (1 （SSE4.1）和 <code>ecx & (1 （AES-NI）等只是辅助参考，不是 AVX 必要条件
为什么只查 __cpuid(1) 不够？还要看 __cpuid(7)
AVX2、AVX-512 这类扩展不在 leaf=1 里暴露。leaf=7（带 ecx=0）才是现代扩展的主入口。比如 AVX2 支持由 ebx 的第 5 位（bit 5）标识；而 AVX-512F（基础指令集）在 ebx 第 16 位。
立即学习“C++免费学习笔记（深入）”；
注意点：
- 调用前必须确认
__cpuid(0)返回的eax≥ 7，否则leaf=7无效（老 CPU 如 Core2 不支持） -
__cpuid(7, eax, ebx, ecx, edx)的ecx参数必须传 0，否则行为未定义 - AVX-512 还有多个子功能（如 VL、BW、DQ），各自对应不同 bit，不能只看
ebx[16]就认为全量可用
Windows 下用 IsProcessorFeaturePresent 可靠吗？
不可靠。这个 API 只反映 Windows 内部的“是否启用该特性”，不等于 CPU 硬件能力。例如：Win7 默认禁用 AVX-512，即使 CPU 支持，IsProcessorFeaturePresent(PF_AVX512F_INSTRUCTIONS_AVAILABLE) 也返回 FALSE；而 Win10 20H1+ 才开始有条件启用。它本质是 OS 策略开关，不是硬件探测接口。
所以：
- 做编译时分支（如
#ifdef __AVX__）依赖的是编译器宏，和运行时实际支持无关 - 真正做运行时 dispatch，必须手撸
__cpuid，且按 leaf 分层查 - Linux 下没有等价 API，只能靠
cpuid指令或getauxval(AT_HWCAP)（但后者不暴露 AVX2/AVX512）
常见误判场景和绕不过去的坑
最典型的错误是：只查了 edx 的 SSE 位（bit 25）或 ecx 的 SSE4.2（bit 20），就认为 AVX 可用——这两者和 AVX 完全无关。
另一个隐蔽坑是虚拟化环境：某些 VM（如 VirtualBox 旧版）默认不透传 XSAVE 功能，OSXSAVE 位为 0，此时即使宿主机支持 AVX，客户机里执行 AVX 指令仍会崩溃。需手动开启 CPU 特性透传（如 VBox 的 –hwvirtbox 或 VMware 的 cpuid.1.eax = "...." 配置）。
最后提醒：__cpuid 在 x86-64 下始终可用，但必须确保当前线程没被迁移到不支持该指令的老核上（多代混合 CPU 场景下，调度器一般不会这么干，但实时系统需额外防护）。
