[jeffbee]

Huh, that is interesting how they do that. They are enabling SHA instruction support based on CPUID and without respect to the value of GOAMD64. I did not realize Go was doing that.

[monocasa]

AFAIK, the sha256 extension isn't a part of any of the x86_64 microarchitecture levels, so a cpuid check is most appropriate here at the moment.

[jeffbee]

Fair point. But what surprised me was the way HasAVX2 is getting set. It is set on the hardware that has AVX2, even if you set GOAMD64=v1.

[burntsushi]

Yup, that's standard, including in other ecosystems. It's what I do in ripgrep for example when your target is just standard `x86_64` (v1). GNU libc does it as well. And I believe Go has been doing it for quite some time. (The specific one I'm aware of is bytes.Index.)

This was especially important back before the days of v1/v2/v3/etc of x86_64, since Linux distros distributed binaries compiled for the lowest common denominator. So the only way you got fast SIMD instructions (beyond SSE2) was with a CPUID check and some compiler features that let you build target specific functions. (And I'm not sure what the status is of Linux distros shipping v1/v2/v3/etc binaries.)

[als0]

In case anyone else was wondering what this is about, here's some useful background https://github.com/golang/go/issues/45453