cmd/go: provide build tags for architecture environment variables

[mdempsky]

This proposal is to have cmd/go automatically set build tags when architecture environment variables are specified.

If an architecture option GO[arch]=[option] is enabled, then cmd/go should set the [arch].[option] build tag. For example, if GOARM=6 is enabled, then cmd/go should set the "arm.6" build tag; if GOARM=7 is enabled, then it should set both the "arm.6" and "arm.7" build tags (since GOARM=7 is a superset of GOARM=6).

Precedent: We already set goexperiment.foo for each GOEXPERIMENT=foo option that's set.

Questions:

• What to do about default flags? Do we need/want to still set "arm.5", even though that's always implied?

• GOARM uses just "5", "6", "7", but GOPPC64 uses "power8", "power9". Should cmd/go use "ppc64.power9"? Or should it be "ppc64le.power9" for GOARCH=ppc64le?

• What about hardfloat/sse2 vs softfloat? Is there any reason to provide 386.sse2, or should users just check for !386.softfloat? In fact, since softfloat exists across architectures, maybe a common "softfloat" tag should be used instead or in addition?

[bcmills]

What to do about default flags? Do we need/want to still set "arm.5", even though that's always implied?

Is it possible that we will add subset options in the future? (For example, something intermediate between AMD64 v1 and v2?) If so, then I think we should set a build tag for the default, so that carefully-written code can fall back to a platform-independent implementation if compiled on a subset smaller than that default (such as in the case of the 386 softfloat transition).

[mdempsky]

Is it possible that we will add subset options in the future? (For example, something intermediate between AMD64 v1 and v2?)

I'm hoping we don't have to, but I wouldn't want to rule it out yet either.

[rsc]

GOWASM established the pattern that this environment variable can be a comma-separated list.
We were also thinking about this for GO386 when we introduced "387" etc. If there were another axis, we'd do comma-separated. (For RISC-V, we would especially need the comma-separated list for the extensions.)

So we need to figure out how a list maps. Presumably each item in the list becomes a separate "arch.thing" tag.

We also need to figure out inclusion. Presumably if you write code with a special case for //go:build amd64.v2 and then the next day v3 comes out, you want that code to still work. So these should be matched by "that setting and all future ones that imply it", same as Go versions (the go1.11 tag is set in Go 1.12 and later as well as Go 1.11). In particular, arm.5 would be true even if we are building with GOARM=6. You'd have to say arm.5 && !arm.6 to get 5-only. (It's nice to have real boolean expressions!)

It doesn't seem like we should apply any special shortenings like ppc64le.9. Let's just use what the environment variable syntax is. (ppc64le.power9 makes sense for ppc64le anywaybecause they call the architecture "POWER9".)

[rsc]

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

[rsc]

Will leave in the minutes for another week before moving to likely accept, but it seems like it's headed there. Last call for objections.

[rsc]

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

[rsc]

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

[gopherbot]

Change https://go.dev/cl/421434 mentions this issue: go/build: add GO$GOARCH-based ToolTags

[gopherbot]

Change https://go.dev/cl/422615 mentions this issue: cmd/go: make cfg.BuildContext.ToolTags same order with build.Default.ToolTags