Go 汇编里怎么调用 AVX2 指令
Go 原生不支持在高级语法中直接写 SIMD，必须进汇编层；但它的汇编是伪汇编（plan9 风格），不是直接贴 Intel 语法。想用 VPMULLD 或 VADDPS 这类指令，得先确认目标平台支持 AVX2，再用 TEXT 定义函数，在 asm 文件里写 plan9 格式指令。
常见错误是把 x86-64 的 NASM 语法直接抄进去，比如写 vpmulld %xmm0, %xmm1, %xmm2 —— Go 汇编不认这种操作数顺序，也不支持寄存器前的 %。正确写法是 VPMULLD X0, X1, X2（大写寄存器名，无符号，源/源/目标顺序）。
- 必须用
//go:toolchain gc+//go:noescape注释控制内联和逃逸，否则编译器可能绕过你的汇编 - 所有向量寄存器用大写：X0–X31（AVX-512 下），AVX2 用 X0–X15 即可；别混用 X 和 Y（Y 是旧版 YMM，Go 汇编统一用 X）
- 参数传递走栈或通用寄存器（如 AX、BX），不能直接把
[]float32地址塞进 X 寄存器——得先用MOVQ把切片底层数组指针加载出来 - AVX2 指令在 Go 1.17+ 才稳定支持；低于此版本可能触发
unknown instruction错误
为什么 runtime/internal/sys 里的 HasAVX2 总是 false
这个常量不是运行时检测结果，而是编译期静态标记：它只反映构建 Go 工具链时主机是否支持 AVX2，跟当前运行环境完全无关。所以即使你在一台 i7-8700K 上跑程序，sys.HasAVX2 仍可能是 false——因为 Go 编译器本身是在 CI 机器上用无 AVX2 的 CPU 构建的。
真要运行时判断，得自己调用 cpuid。Go 标准库没暴露这个能力，必须手写汇编读取 EDX 第 28 位（AVX 支持）和 ECX 第 5 位（AVX2 支持）：
立即学习“go语言免费学习笔记（深入）”；
TEXT ·hasAVX2(SB), NOSPLIT, $0
MOVL $1, AX
CPUID
TESTL $0x20, CX
JZ no
MOVB $1, ret+0(FP)
RET
no:
MOVB $0, ret+0(FP)
RET
- 别依赖
unsafe.Sizeof或reflect判断向量长度——它们不感知 CPU 特性 - 跨平台分发时，若未做运行时检查就执行 AVX2 指令，会直接触发
illegal instruction信号，进程崩溃 - Linux 下可用
cat /proc/cpuinfo | grep avx2辅助验证，但不能替代代码中的检测
用 GOAMD64=v3 能代替手写汇编吗
不能。这个构建标签只影响 Go 编译器生成的**自动向量化代码**（比如 for 循环里的 float64 加法），它不会让你调用任意 AVX2 指令，也不能控制数据对齐、内存访问模式或寄存器分配。它更像一个“允许编译器尝试优化”的开关，而非“启用 SIMD 编程接口”。
实际表现差异很大：对简单连续数组求和，GOAMD64=v3 可能自动用上 VADDPD；但如果你要实现一个自定义的 SIMD-aware 哈希或图像卷积，它完全无能为力。
-
GOAMD64=v3要求目标 CPU 支持 AVX，但不保证 AVX2；v4 才要求 AVX2，且仅 Go 1.21+ 支持 - 开启后生成的代码可能比手写汇编慢 10–30%，尤其当数据未按 32 字节对齐时，编译器会插入额外的 shuffle 指令
- 无法控制中间结果是否留在寄存器里——手写汇编可以明确用
X0存累积值，避免反复读写内存
内存对齐没处理好，VPBROADCASTD 就 panic
AVX2 大多数 load/store 指令（如 VMOVDQA32）要求地址 32 字节对齐；如果传入的 []int32 底层指针是 8 字节对齐的（Go 切片默认行为），执行时会触发 signal SIGBUS，而不是 panic。这个错误不报具体行号，只显示 “fatal error: unexpected signal”，极难定位。
解决方式只有两个：要么确保输入数据对齐（用 aligned_alloc 或 unsafe.AlignedAlloc），要么改用非对齐指令（如 VMOVDQU32），但后者通常慢 1–2 个周期，且某些老 CPU 不支持。
- 用
unsafe.Offsetof检查结构体字段偏移，但切片头里的array指针对齐不可控——别试图靠 struct padding 强制对齐切片 -
VPBROADCASTD本身不要求对齐，但它常和VMOVDQA32配套使用；单独用它没问题，一组合就崩 - 调试时加
gdb --args ./prog，断在sigtramp，用x/i $pc看最后执行的指令，确认是不是 AVX load
真正麻烦的是：同一段汇编，在本地开发机跑得好好的，部署到某批云服务器就挂——大概率是那批机器的 Go 运行时用了不同版本的 musl/glibc，导致 malloc 对齐策略不同。这种问题不会出现在日志里，得靠监控信号量捕获。
