all: add GORISCV64 environment variable

[markdryan]

Overview

Go currently targets the RV64G instruction set when building for GOARCH=riscv64. This gives the compiler and hand-coded assembly language functions in the runtime and standard library access to scalar integer, multiply, divide, scalar floating point, atomic and fence instructions and some counters, but little else. RISC-V does define a number of extensions that could be used in the compiler (and the standard library) to improve performance and reduce code size. For example, the Bit Manipulation extensions could be used to speed up array access and implement an intrinsic for math/bits.OnesCount. The Vector extensions could be used to improve some of the hand-coded assembly language functions, such as memmove. However, the compiler cannot currently use those extensions without a runtime check (which it can't currently do either as it happens) as it needs to generate code that will run safely on all RV64G devices.

Proposal 61416 x/sys/unix, x/sys/cpu: use the RISC-V Hardware Probing Interface on Linux proposes a method of determining which extensions exist at runtime (on Linux). This proposal suggests a method to determine the existence of useful extensions at compile time. Similar mechanisms exists for other architectures supported by Go and are implemented via the use of an environment variable, e.g., GOAMD64. Here we propose adding a new RISC-V specific environment variable, GORISCV64, that could be used by the compiler and assembly language functions to determine which extensions can be safely used without runtime checks.

Suggested values for GORISCV64

RISC-V defines a set of profiles. Each of these profiles specify a base ISA and a set of mandatory extensions. For example, devices supporting the RVA20U64 profile must support RV64GC providing access to the compressed instruction set. Devices supporting RVA22U64 must additionally support Zba, Zbb and Zbs. RVA23U64 (which is not yet ratified) currently mandates the Vector extension and Pointer Masking.

This proposal recommends using the names of these standardised profiles, converted to lowercase, as valid values for the GORISCV64 environment variable, with one exception. There is no profile that corresponds to what the compiler currently targets, RV64G, so RV64G would also be a valid value of GORISCV64 and the default.

In summary, we would have

GORISCV64 Value	buildcfg.GORISCV64	Build Tags	Potential Benefits
rv64g	0	riscv64.rv64g	The default and what Go currently targets
rva20u64	20	riscv64.rv64g, riscv64.rva20u64	Would allow the compiler to generate compressed instructions
rva22u64	22	riscv64.rv64g, riscv64.rva20u64, riscv64.rva22u64	Would allow the compiler to generate Zba, Zbb and Zbs instructions without runtime checks

Once RVA23U64 is ratified a fourth permissable value could be supported

GORISCV64 Value	buildcfg.GORISCV64	Build Tags	Potential Benefits
rva23u64	23	riscv64.rv64g, riscv64.rva20u64, riscv64.rva22u64, riscv64.rva23u64	Would potentially allow the use of vector instructions in hand written assembler without runtime checks. Pointer masking might be useful.

This proposal just covers the addition of the new environment variable. Extra work would be needed to take advantage of this variable such as adding support in the assembler for the extensions mandated by the profiles and updating the compiler and standard library routines to use them. I'll enter separate issues for these items.

Open Issues

This section will capture issues raised in the discussion below that do not yet have an agreed resolution.

• Should the default value of GORISCV64 be rv64g (what the compiler currently targets and isn't actually a profile) or rva20u64 which makes the compressed instruction set mandatory?
• Should GORISCV64 be restricted to rv64g and the profile names only (or perhaps just the profile names) or should we allow users to specify a complete ISA string? Complete ISA strings allow individual extensions to be specified and can include profile names but introduce additional complexity.
• The current builders only support rv64g and rva20u64. These builders do support some but not all of the mandatory extensions in rva22u64. Restricting GORISCV64 to profile names (and rv64g) only will delay improvements to the compiler that can take advantage of these extensions, notably, Zba and Zbb, until we have builders that support rva22u64.

[bcmills]

(attn @golang/riscv64)

[4a6f656c]

See also #47373 (cc @benshi001, @wdvxdr1123)

[4a6f656c]

I agree that a GORISCV64 environment variable is likely needed and I think that it is now a reasonable point in time to introduce it. That said, some points to consider:

• Runtime detection is preferred - as far as possible, we should prefer runtime detection over compile time selection - there are a number of use cases (e.g. cross compilation, binary package builds, etc) where the lower common denominator has to be selected, in order to work across all hardware/platforms. There are cases where this works (e.g. switching to a SHA512 implementation that uses specific instructions at runtime) and cases where it does not (e.g. compiler rewrite rules).

• Compressed instructions - while it is true that Go currently targets rv64g, in reality there is probably no reason that this cannot be rv64gc which would presumably allow RVA20U64 as the base profile. I'm not aware of hardware/environments existing that meet rv64g but do not have c support - other compilers and operating systems target rv64gc as well (as an aside, I have various compressed instruction diffs floating around).

• Profiles versus reality - one issue to consider is that while I think the use of profiles is a nice and clean approach, in reality this does not work well. For example, the Starfive VisionFive 2 has support for rv64gc however only includes zba and zbb. This means that on this hardware RVA22U64 could not be used since zbs is not supported. One previous suggestion was to use some form of feature list - most riscv64 environments provide this in a form like rv64imafdc_zba_zbb, which would be readily parsable. The specification of a profile would simply map to a similar string.

• Builders and testing - adding new instructions and compiler rules that use additional extensions is problematic if the builders are not actually testing them. The current builders are SiFive HiFive Unleashed and SiFive HiFive Unmatched based, which are rv64imafdc (I don't have access to an Unmatched to confirm, but I believe it is the same as the Unleashed). I should be bringing a Starfive VisionFive 2 online for the openbsd/riscv64 builder soon, which would make zba and zbb available. Otherwise we probably need to consider additional builders and/or test environments that provide coverage for new code.

[wdvxdr1123]

The current builders are SiFive HiFive Unleashed and SiFive HiFive Unmatched based

I think linux-riscv64-unmatched is actually running on Starfive VisionFive2 now. cc @mengzhuo

[mengzhuo]

The current builders are SiFive HiFive Unleashed and SiFive HiFive Unmatched based

I think linux-riscv64-unmatched is actually running on Starfive VisionFive2 now. cc @mengzhuo

FYI There is one builder unmatched025.farm.rvlab.org based Unmatched and two VisionFive2 from my homelab, it's a temporary solution since "rvlab" is rebuilding their build farm.

[markdryan]

• Profiles versus reality - one issue to consider is that while I think the use of profiles is a nice and clean approach, in reality this does not work well. For example, the Starfive VisionFive 2 has support for rv64gc however only includes zba and zbb. This means that on this hardware RVA22U64 could not be used since zbs is not supported. One previous suggestion was to use some form of feature list - most riscv64 environments provide this in a form like rv64imafdc_zba_zbb, which would be readily parsable. The specification of a profile would simply map to a similar string.

While it is true that limiting GORISCV64 to profile names wouldn't help us generate better code for the existing SBCs on the market, RVA22U64 does seem to be gaining some traction. SiFive and T-HEAD have announced RVA22U64 compatible processors and Android is targeting RVA22U64 going forward.

The reason I proposed using profile names and nothing else (apart from RV64G) for valid values for GORISCV64 is that this solution is similar to what is used on other architectures supported by Go. There is also the observations in the RISC-V profiles document that the ability to target individual extensions can lead to a "combinatorial explosion in possible ISA choices" and that "long and unwieldy ISA strings [are] required to encode common sets of extensions, which will continue to grow as new extensions are defined."

I guess the question we need to answer is whether it's worth the additional complexity of handling arbitrary ISA strings so we can target at compile time existing boards such as the VisionFive2 or future boards that implement extensions that are optional in their supported profile? Or is the simpler solution of targeting the mandatory extensions of the profiles at compile time and detecting everything else at runtime sufficient?

[rsc]

What is the set of values that should be accepted here? And what build tag or tags should be enabled for each value?
For x86 we have v1 v2 v3 and if you set GOAMD64=v3 it also sets the v2 build tag because v3 implies v2.
(Otherwise v2-aware code would not be used with v3, making v3 possibly slower than v2.)
Is there any such relationship here?

[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

[luhenry]

What is the set of values that should be accepted here? And what build tag or tags should be enabled for each value?

@markdryan is coming back from PTO next week, so let me just chime in before he can give a more in-depth answer.

The proposal is to use RISC-V profile names, with GORISCV64=RVA20U64 or GORISCV64=RVA22U64 for example, and a default to GORISCV64=RV64G. These map directly to existing RISC-V profiles, RVA20U64 and RVA22U64 respectively.

The build tag enabled by each of this value would match directly the mandatory extensions defined by each profile. For RVA22U64, it would map to enabling RV64GC + Zba + Zbb + Zbs + Zihintpause + Zicbop + Zicboz + Zicbom + Zfhmin + Zkt. Note that not all of these extensions are currently taken advantage of in Go, but we are working on doing just that at the moment.

The motivation behind using profiles is already explicitely outlined in the RISC-V profile spec:

Profiles specify a much smaller common set of ISA choices that capture the most value for most users, and which thereby enable the software community to focus resources on building a rich software ecosystem with application and operating system portability across different implementations

This is, AFAIU, the same approach taken by Go for the GOAMD64 variable.