__builtin_cpu_supports("avx512f")可运行时检测AVX-512基础支持，需GCC≥7.1/Clang≥6.0且字符串为编译期字面量；AVX-512模块化，须依次检查avx512f、avx512vl、avx512bw等扩展，MSVC不支持该函数。
用 __builtin_cpu_supports 快速判断（GCC/Clang）
如果你用的是 GCC 7.1+ 或 Clang 6.0+，最省事的方式是直接调用编译器内置函数：__builtin_cpu_supports("avx512f")。它在运行时查 CPUID，返回 true 表示基础 AVX-512 指令集（avx512f）可用。
注意：AVX-512 是模块化设计，avx512f（Foundation）只是起点，后续还有 avx512vl、avx512bw、avx512cd 等扩展。要确认完整支持，得逐个查：
-
__builtin_cpu_supports("avx512f")—— 必须为真，否则其他都无效 -
__builtin_cpu_supports("avx512vl")—— 支持向量长度可变（如 128/256-bit 寄存器上的 AVX-512 操作） -
__builtin_cpu_supports("avx512bw")—— 支持字节/字整型运算（常用于图像处理）
这个函数不依赖外部库，也不需要手写内联汇编，但仅限 GCC/Clang；MSVC 不支持。
Windows 下用 __cpuidex 手动查 CPUID（MSVC 或跨平台兼容需求）
MSVC 没有 __builtin_cpu_supports，得自己调用 __cpuidex 查 CPUID 叶子 0x00000007 的 ECX 和 EDX 位域。AVX-512 相关标志从该叶子开始定义：
立即学习“C++免费学习笔记（深入）”；
- ECX[16] 对应
avx512f - ECX[17] 对应
avx512dq - EDX[2] 对应
avx512vl - EDX[3] 对应
avx512bw
关键点：必须先确认 cpuid 最大功能号 ≥ 0x00000007（通过 __cpuid 查叶子 0），否则读 __cpuidex(0x7, 0) 可能返回全零或未定义值。另外，某些老系统或虚拟机即使 CPU 支持，也可能因 BIOS/OS 禁用 AVX-512 而使这些位为 0。
Linux 下读 /proc/cpuinfo 仅作参考，不可用于运行时决策
cat /proc/cpuinfo | grep avx512 能看到 avx512f、avx512vl 等 flag，但这只反映内核启动时检测到的硬件能力，不代表当前进程能实际使用——比如容器里被 prctl(PR_SET_XFIT, ...) 禁用，或系统启用了 AVX-512 电源管理限制（如 Intel Speed Select 技术关闭了部分执行单元），/proc/cpuinfo 仍会显示 flag。
所以它适合调试和人工验证，不能替代运行时检测。尤其在云环境或容器中，依赖这个判断大概率出错。
AVX-512 启用后还要检查 OS 支持和寄存器状态
即使 CPUID 显示支持，也得确保 OS 已启用 XSAVE/XRSTOR 机制并分配了足够大的上下文空间（AVX-512 使用 ZMM0–ZMM31，每个 512-bit，上下文体积远超 AVX2）。Linux 4.4+ 默认支持，但旧内核或某些嵌入式发行版可能没打开 CONFIG_X86_INTEL_CMT 或相关配置。
更隐蔽的问题：某些 CPU（如 Cascade Lake）需 BIOS 中开启 “Intel Advanced Vector Extensions 512” 选项，且部分型号默认关闭；即使代码跑通，ZMM 寄存器高 256-bit 部分若未被 OS 正确保存/恢复，会导致线程切换后数据损坏——这种 bug 很难复现，但后果严重。
真正稳妥的做法是：先用 __builtin_cpu_supports 或 __cpuidex 确认硬件能力，再在关键路径前插入一条简单 AVX-512 指令（如 _mm512_set1_epi32(42)）并捕获 SIGILL，双重保险。
