all: add GOARM64=v8.1 and so on

[aktau]

Similar to: #45453.

Each ARM sub-architecture iteration adds some new instructions, some of which may be useful for Go. For example, ARMv8.2 introduced:

• v8.2: FEAT_LSE, Large System Extensions (though it looks like there have been changes to this extension in later iterations)
  • LDADD (atomic add), useful for atomic.Add*.
  • LDSETAL (atomic or), see sync/atomic: add OR/AND operators for unsigned types #61395.
  • CAS (compare and swap), useful for atomic.CompareAndSwap*
  • SWP (swap), useful for atomic.Swap*
  • ...more similar atomic instructions.

These instructions are already used after a capability check (thanks @prattmic for pointing this out). These capability check jumps predict perfectly, but the blocks aren't tiny either (godbolt):

It might be useful to define some new possible GOARM values akin to GOAMD to elide these checks, potentially increasing performance and reducing binary sizes by some tiny amount. I have not done any performance measurements, but received hearsay from colleagues that using these instructions was a significant win for them (but I did not ask whether they used a capability check or whether they were comparing with always using the less capable version).

Other potential candidate:

• v8.1: FEAT_CRC32, Changes to CRC32 instructions (made mandatory)
• v8.8: FEAT_MOPS, Standardization of memory operations, slides). runtime.memmove is >1% of cycles when looking at data available here. Using FEAT_MOPS unconditionally could also have good icache effects.
• v8.8: FEAT_HBC, Hinted conditional branches (perhaps indented branches or anything that can be proven to contain a non-nil error via dataflow could be hinted "unlikely").

[ianlancetaylor]

The currently valid values for GOARM are 5, 6, and 7. Are you suggesting that we add 8 and 8.1 as valid values?

[Jorropo]

It would be surprising to have GOARM used both by GOARCH=arm and GOARCH=arm64 imo should be a GOARM64.

[ianlancetaylor]

Good point, thanks, it should be GOARM64.

That may mean that we don't need to be compatible with GOARM, and could use v8, v8.1, ....

[rsc]

The leading v seems like it emphasizes that this is the ARMv8.1 v numbers not any other kind of ARM numbering (like ARM11 which implements ARMv6). It also makes sure that nothing tries to strconv.Atoi("8") and then get messed up by strconv.Atoi("8.1"). So I think we should keep the leading v.

[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

[scweng]

I would like to sound extra support for retaining v and emphasize that it's not a number -- a number is not enough to represent Arm capabilities.

Currently Arm defines Armv8.0~Armv8.9 and Armv9.0~Armv9.3, but Armv9.0 is not the next version of Armv8.9, it actually branched off Armv8.5. Parsing the version into number will create an illusion of linear progression.

Further, each of these versions are actually "extensions." Each extension defines a number of "features," e.g. FEAT_LSE, with some being mandatory and some optional. Some, like LSE, are optional up to a version (8.0) and then become mandatory later (8.1).

Because of this, both gcc and clang have complicated ways to precisely specify what Arm version to target: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html#index-march-2, https://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html

In this system, the compiler cannot assume the target machine has LSE instructions if we only compile with -march=armv8-a and thus needs to emit capability tests. But -march=armv8-a+lse means targeting a machine that implements all the mandatory features defined in the base v8 ISA, but also assume the machine has LSE, which would be enough for the compiler to skip the capability test and use instructions like LDADD directly.

My suggestion is we also implement similar notations in GOARM64 so that GOARM64=v8.1-a and GOARM64=v8-a+lse both suffice in using LSE instructions directly.