Isn't this already somewhat the case?

The Go toolchain may also generate newer instructions, but guarded by dynamic checks to ensure they're only executed on capable processors. For example, with GOAMD64=v1, math/bits.OnesCount will still use the POPCNT instruction if CPUID reports that it's available. Otherwise, it falls back to a generic implementation.

@seankhliao this would happen at compile time allowing the compiler to omit the dynamic check, the thing you linked compiles to a runtime check:
https://godbolt.org/z/8az84vv6x (left side is GOAMD64=v1, right side is GOAMD64=v3)

Note: this already exists, however you have to precisely tell the compiler which level you are targeting, what I am asking for is a level that is whatever best the current host supports.

FWIW gcc and clang have the same feature with -march=native.

CC @golang/runtime

When I first read this I reached the same conclusion as @seankhliao that this behavior is already the default, but I think both of us misunderstood what you were proposing.

I think what's implied in your proposal is that you want "native" to mean "whatever architecture is available on the system where the compiler is running", because you assume that the computer where the program will eventually run will either be the same computer or will have an identical CPU. Is that right?

I think others typically build one binary and ship it to many different servers to run, and so the runtime detection is what they want. It sounds like you are instead planning to build and run the executables on the same computer, and so you're intending to ask the compiler to assume that's true and look for opportunities to optimize based on what it can learn about the CPU that's running the compiler.

@apparentlymart exact, I'll try adding "the compiler will ..." to the proposal hopping to make it clearer.

Maybe if I just described the proposal as GOAMD64=local go build do like clang -march=native it would have helped more.
(actually they are slightly different because the clang backend is more granular than v1, v2, v3, v4, here this limits to the microarchitecture compilation support already existing)

Just a note that if we do this for GOAMD64 we should presumably also do it for the GO${GOARCH} environment variables.

Given that GOAMD64 can really help in some cases like -race being ~15% faster with v3 (https://go-review.googlesource.com/c/go/+/444396), I'd like to make use of it in CI to run go test -race ./... as well. I had thought about using GOAMD64=v3, but that assumes a little too much about what CPU the shared CI machine is using. GOAMD64=native would be an easier alternative.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

According to https://developers.google.com/style/inclusive-documentation#features-and-users we should avoid "socially-charged terms" including "native". I have retitled this to GOAMD64=local (as in the local machine), which matches other uses of local in the Go toolchain such as GOTOOLCHAIN=local and the "local package" concept in the compiler and is, at least to me, clearer anyway. (Perhaps GOAMD64=native would mean the original x86 instructions, analogous to "native species", something "native to x86". If you haven't heard of GCC's -march=native, the fact that native is machine-specific is not clear. Local at least evokes something about the local machine.)

Now back to technical discussion...

Another point in favour of this proposal is that it's not so easy to figure out which "level" your CPU supports; checking Wikipedia I see stuff like "CMPXCHG16B" for v2, but I don't see that in /proc/cpuinfo (looking it up, it's included in all 64bit CPUs, but that's not very obvious). My 2021 laptop CPU also doesn't include AVX (it's a cheap Celeron), so "circa 2015: Haswell and Excavator" isn't quite as simple either.

Another way to solve this might be something like a go tool arch or go tool arch local command; then you can do GOAMD64=$(go tool arch) or even GOAMD64=$(ssh myserver 'go tool arch').

One of the nice things about this is that you can easily see what's being selected. You can check this after the build with go version -m my-go-bin and check the build GOAMD64 line, but this seems a more convenient – it just makes things a bit less opaque which can be useful when compiling for another machine (e.g. "what GOAMD64 does the server I'm compiling for support?") It might also be useful for some scripts or other things.

It would be nice if "go version -m" showed the real GOAMD64 not local.
Probably 'go env GOAMD64' needs to say local.
Some way to interrogate the meaning of local would be nice.

We should add the sub-arch values to the 'context' struct in go list, so that you can run
go list -f '{{context.GOAMD64}}'.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

@rsc does the likely accept also includes other architectures like GOARM or just GOAMD64 ?

@Jorropo, all the architectures.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group