__builtin_cpu_supports("avx2")可运行时检测avx2支持，需gcc≥4.9或clang≥3.5，字符串必须小写"avx2"，在非x86/x64平台返回false，且不依赖编译选项。
用 __builtin_cpu_supports 快速判断（GCC/Clang）
GCC 和 Clang 在较新版本中提供了内建函数 __builtin_cpu_supports，能直接在运行时检测 CPU 是否支持 AVX2。它不依赖外部库，编译期无需额外 flag，但要求编译器版本 ≥ GCC 4.9 或 Clang 3.5。
常见错误是传错字符串：必须用小写 "avx2"，不是 "AVX2" 或 "avx-2"；传入其他字符串（如 "avx"）会返回 false，但不会报错。
- 示例用法：
if (__builtin_cpu_supports("avx2")) { // 可安全调用 _mm256_add_epi32 等 AVX2 指令 } - 注意：该函数在非 x86/x86_64 平台（如 ARM）上返回 false，且无法在编译期做 constexpr 判断
- 如果用
-march=native编译，__builtin_cpu_supports("avx2")仍可能返回 false——它查的是当前运行机器，不是编译机器
手动调用 cpuid 指令（跨编译器、更底层）
Windows、GCC、Clang 都能用内联汇编或 __cpuid/__cpuidex 调用 CPUID 指令查功能位。AVX2 支持由 ECX[5] 标志位指示（CPUID leaf 7, subleaf 0）。
容易踩的坑是漏查前提条件：必须先确认 OS 支持 XSAVE/XRSTOR（否则即使 CPU 支持 AVX2，也不能安全使用），这需要检查 ECX[27]（XSAVE）和 EDX[2]（OSXSAVE）。
- 典型流程：
int cpuinfo[4]; __cpuid(cpuinfo, 1); // 先查 basic info if (!(cpuinfo[3] & (1
- MSVC 用户必须用
__cpuidex（不是__cpuid），否则 subleaf 0 的结果不准确 - Linux 下若禁用
XSAVE（如 kernel boot 参数noxsave），即使 CPUID 返回 true，执行 AVX2 指令也会触发 #UD 异常
编译期检测和运行时 fallback 的配合方式
只靠运行时检测不够——你得让编译器生成两套代码：一套用 AVX2 内建函数（如 _mm256_loadu_si256），一套用 SSE2 回退路径。不能指望编译器自动做多版本分发。
关键点在于：AVX2 指令集启用与否，和编译选项 -mavx2 是两回事。-mavx2 只影响编译器能否生成 AVX2 指令，不代表运行时一定可用；而 __builtin_cpu_supports("avx2") 返回 true 也不代表你已用 -mavx2 编译过对应函数。
- 正确做法是把 AVX2 逻辑单独写成
__attribute__((target("avx2"))) void avx2_kernel(...)函数（GCC/Clang），再用运行时分支调用 - MSVC 对应写法是
__declspec(align(32))+#pragma avx2块，但需确保调用前已验证支持 - 别在全局作用域里无条件调用 AVX2 内建函数——链接时没问题，运行时可能 SIGILL
为什么 std::is_constant_evaluated() 或模板特化不适合这事
有人想用 constexpr 检测 CPU 支持度，这是行不通的。CPUID 是运行时特权指令，无法在编译期执行；std::is_constant_evaluated() 查的是求值上下文，不是硬件能力。
模板参数硬编码 avx2_enabled = true 更危险：它会让所有平台都编译 AVX2 指令，哪怕目标机器是老 Atom 或 AMD K10——运行直接崩溃。
- 唯一可行的编译期代理是构建系统层面的检测（如 CMake 的
check_cxx_compiler_flag），但它只能告诉你“当前编译机支持”，不能代替运行时检查 - 如果你打包静态二进制分发，必须同时提供运行时检测 + 多代码路径，不能省略 fallback
- 某些云环境（如 AWS Graviton）根本没 x86 CPUID，此时任何基于
cpuid的逻辑都会失效，需提前识别架构
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
