_mm256_load_ps要求32字节对齐，否则触发SIGILL；未对齐需用_loadu_ps（慢1–3周期）或对齐分配（如_mm_malloc(…, 32)），尾部不足8元素须单独处理，整数掩码不可直喂浮点blend指令。
_mm256_load_si256 会崩溃，_mm256_loadu_ps 能跑但慢——SIMD 加速不是套几个 intrinsic 就完事，真正卡住性能的是内存对齐、尾部处理和指令类型错配。
为什么 _mm256_load_ps 一用就 SIGILL？
AVX2 的 _mm256_load_ps 要求指针地址是 32 字节对齐的，否则直接触发 SIGILL（Linux）或 EXCEPTION_ILLEGAL_INSTRUCTION（Windows）。new float[n]、std::vector<float></float> 或栈上普通数组默认都不满足这个条件。
- 检查是否对齐：打印地址
printf("%p", ptr)，末两位是00（十六进制）才表示 32 字节对齐 - 正确分配方式：
float* a = (float*)_mm_malloc(n * sizeof(float), 32)或 C++17 的float* a = (float*)aligned_alloc(32, n * sizeof(float)) - 栈数组可用
alignas(32) float a[1024]声明，但注意大小必须是 32 的整数倍，否则越界访问仍可能出问题
_mm256_loadu_ps 和 _mm256_load_ps 性能差多少？
未对齐加载 _mm256_loadu_ps 在现代 CPU 上比对齐版多 1–3 个周期延迟。对小数组或高频调用场景（比如内层循环每轮都 load），这个差距会放大成可观测的吞吐下降。
- 实测典型影响：在 Skylake 架构上，连续 100 万次浮点加法，对齐版本比未对齐快约 8–12%
-
_mm256_load_ps仅适用于已知对齐的指针；若不确定，宁可先用_mm256_loadu_ps跑通逻辑，再切到对齐路径做性能验证 - 编译器自动向量化（如
-O3 -mavx2）通常只对对齐内存生成vloadps指令；未对齐时会降级为多条指令或放弃向量化
整数比较结果不能直接喂给浮点 blend 指令
_mm256_cmplt_epi32 返回 __m256i，每个 32 位元素是全 0 或全 0xffffffff；而 _mm256_blendv_ps 期望的掩码是 __m256，且只读取每个 32 位元素的最高位。两者位解释不兼容，混用会导致 blend 行为完全错乱。
立即学习“C++免费学习笔记（深入）”；
- 整数比较后要 blend 整数 → 用
_mm256_blendv_epi8 - 浮点比较后要 blend 浮点 → 先用
_mm256_cmp_ps(a, b, _CMP_LT_OS)，再喂给_mm256_blendv_ps - 特别注意 NaN：用
_CMP_LT_OS（Ordered, Signaling）而非_CMP_LT_OQ，避免 NaN 静默失败
尾部元素怎么安全处理？
数组长度不是 8 的整数倍时，不能只靠 if (n % 8) 简单跳过。最后不足 8 个元素必须单独处理，否则越界读写会破坏相邻内存或触发段错误。
- 推荐做法：主循环处理
i = 0; i ，剩余 <code>n - i个元素用标量循环或 masked load（如 AVX-512 的_mm256_mask_load_ps） - AVX2 下无原生 masked load，可用
_mm256_loadu_ps+_mm256_maskstore_ps配合生成的掩码，但要注意 store 掩码需手动构造 - 更稳妥的方案：提前分配 padding（比如向上对齐到 8 的倍数），并确保 padding 区域可读（如用
memset初始化）
对齐不是“做了就行”，而是要贯穿分配、传递、访问全过程；尾部处理不是“补几行代码”，而是决定你写的 SIMD 是真加速还是假优化的关键分水岭。
