Worth noting that this information is already available as a build tag, like //go:build amd64.v3. Are there cases where an integer value would help?

Also, would this be a constant or a variable? I imagine a constant would be better, given that it's known at build time.

@mvdan If I understand correctly the value is not known at build time. At build time we know the minimum supported microarchitecture level, from the GOAMD64 environment variable. But at run time we know the actual microarchitecture level, which must be at least as high but may be higher. Similarly, a build tag doesn't help here.

Ah, this api would actually fetch the level of the machine running the program, which might well be higher than the one the binary was built for. I see the distinction now.

I think generally its better to directly spell out the specific features that should gate an optimized code path at runtime instead of using microachitectural level. That way optimized code might be triggered more often as it is not conditional on the support of some instructions it doesnt use.

e.g. LZCNT, BMI can be available without AVX2 support.

example code used with internal/cpu:

A use case for this is selecting one among multiple binaries compiled for different GOAMD64 values. I currently use klauspost/cpuid for this exact purpose in https://github.com/CAFxX/mgo.