proposal: cmd/compile: add a flag to support riscv optional extension

[newborn22]

Proposal Details

The RVA23U64 profile specifies a set of extensions, some mandatory and some optional (such as Zacas and Zabha). Currently, however, there is no flag to instruct the Go compiler when to generate code for these optional extensions.

A potential solution is to introduce an environment variable named GORISCV64OPT, which would accept a string array as input. This array would be converted into a map within the compiler. Additionally, macros derived from the input could be passed to the assembler, allowing the use of conditional compilation directives like #ifdef GORISCV64OPT_XXX to control whether optional extension assembly code is included. I also wrote a demo here: https://github.com/zte-riscv/go/pull/64/files#diff-7eb232fb2003a7305dd50315d163ac65a4f06658fecc5f3bf214330995b80e17

[gabyhelp]

Related Issues

• all: add GORISCV64 environment variable #61476 (closed)
• proposal: cmd/compile: add GORISCV64=g #74540
• proposal: cmd/compile: add support for RISC-V B-extension #47373 (closed)
• cmd/compile: change GORISCV64=rva20u64 to include compressed instructions #71105
• cmd/compile, cmd/asm: add support for Zicond extension on riscv64 #75350
• proposal: cmd/go: add GOMIPS64=r2 for mips64r2 code generation #35008 (closed)
• cmd/go: provide build tags for architecture environment variables #45454 (closed)
• all: add GOAMD64 environment variable #45453 (closed)
• pkg/cmd/pr/update/update.go #68505 (closed)

Related Code Changes

• cmd/go: add GORISCV64 environment variable

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[Jorropo]

Not supporting extension level configuration is an intentional decision to avoid maintaining a sprawling matrix of optimizations based on what exact extensions are supported.

We do for some extensions on arm64 the syntax is GOARM64=level,extension,extension2 so we would use the same syntax in GORISCV64.

Personally I think it's reasonable to do so on RISCV, it is very well documented, most extensions are self sufficient such that you do not need to make 8 different optimizations decisions based on if 3 extensions are supported or not.
Sometime you do, I've never seen a case where more than 2 extensions are involved.
We aren't forced to support the complete matrix either, if there is a nasty matrix somewhere we can choose to only implement a best optimization using X+ extensions and a fallback that always work.

On a hardware design note creating RISCV profiles is a process happening over years,
Always you find there are many uncontroversial already specified extensions, and there are a couple more time consuming extensions.
This means when a profile is released it's not uncommon to already have CPUs on the market with the previous profile, and let's say the 50% uncontroversial part of the new profile.
But with our current approach we are not able to use theses uncontroversial extensions CPUs already implements.

---

I would propose that we can append RISCV official extensions name with , to GORISCV64 so for example:

GORISCV64=RVA20U64,Zicond # enable RVA20U64 and Zicond
GORISCV64=RVA20U64,Zicond,B # enable RVA20U64, Zicond and B

When doing so the compiler is allowed to unconditionally use any features of theses extensions.

We would also set riscv64.extensionName build tags, for example riscv64.Zicond & riscv64.B.
Theses would also be set if using a profile that includes theses extensions, for example setting GORISCV64=RVA23U64 would set build tag riscv64.Zicond since RVA23U64 is specified to include Zicond.

Note: in GORISCV64 the first component would always have to be a profile (or g if #74540 is accepted).
Note2: the toolchain would minimize the GORISCV64 variable before ever using it, that means doing GORISCV64=RVA23U64,Zicond would give the same thing as GORISCV64=RVA23U64.

[Jorropo]

cc @golang/riscv64

[mengzhuo]

I think raise an expection that already in profile maybe more appropriate since attributes might read this. https://go-review.googlesource.com/c/go/+/659175

i.e.
"GORISCV64=RVA23U64,Zicond"
"zicond is already in rva23u64"

Another problem, how to support the version of optional extensions? (i.e. "zicond1", "f2p2")

[Jorropo]

i.e.
"GORISCV64=RVA23U64,Zicond"
"zicond is already in rva23u64"

I don't think users should have to find out by trial and error to see what string will go accept.
This can be tricky with meta extensions like B who include other extensions (Zba, Zbb, ...).

However I agree that GORISCV64=RVA23U64,Zicond must be canonicalized to GORISCV64=RVA23U64 before being used for anything including being stored in the binary metadata.

On a simple level, why should the toolchain say no to GORISCV64=RVA20U64,B,Zba when it can clearly understand what you are trying to do ?

---

Implementation details thoughts:

we could encode GORISCV64 as a bitset of all the extensions we know.
Each profile or extension is a bitset of all the included extensions.
Something like

• RVA23U64 would have a lot of bits set (all of the extensions included).
• B would have Zba, Zbb, Zbc, Zbs, Zbkb, Zbkc, Zbkx bits set.
• Zba would only set the Zba bit.

When parsing GORISCV64 we find all the components in the GORISCV64, find their corresponding bitset and OR all the bitsets together.
Then when marshaling the bitset we go the other way, finding the biggest compatible profile / extension first, adding it to the return value, clearing all the bits it covers and repeating the process until we cleared all the bits in our config bitset.

[wangpc-pp]

This should be like the profile support of -march: riscv-non-isa/riscv-toolchain-conventions#36
I second the solution, using GORISCV64, proposed by @Jorropo (I had a downstream implementation for this).

I think raise an expection that already in profile maybe more appropriate since attributes might read this. https://go-review.googlesource.com/c/go/+/659175

i.e. "GORISCV64=RVA23U64,Zicond" "zicond is already in rva23u64"

Another problem, how to support the version of optional extensions? (i.e. "zicond1", "f2p2")

I don't think the version number means anything nowadays, once these extensions are ratified, the version number should be 1.0. The version number is a legacy problem... We may ignore the version number or just use the same syntax in -march.

[newborn22]

So, I think this feature can be implemented in this way initially:

First, we need to define a set of constants that represent each extension.

Then, we should create a new data structure called, for example, Extensions, which should expose interfaces like SetExtension and QueryExtension to allow for setting and querying. Internally, this data structure could be a bitmap or simply a hash map.

After that, the GORISCV64 parsing logic should parse the input string (formatted as something like rva23u64,extension1,extension2), call the SetExtension interface, and finally, the compiler logic would call QueryExtension to check for the extensions it needs and decide how to generate the code.

[newborn22]

So, I think this feature can be implemented in this way initially:

First, we need to define a set of constants that represent each extension.

Then, we should create a new data structure called, for example, Extensions, which should expose interfaces like SetExtension and QueryExtension to allow for setting and querying. Internally, this data structure could be a bitmap or simply a hash map.

After that, the GORISCV64 parsing logic should parse the input string (formatted as something like rva23u64,extension1,extension2), call the SetExtension interface, and finally, the compiler logic would call QueryExtension to check for the extensions it needs and decide how to generate the code.

I'd like to ask if anyone has worked on this issue yet? If not, may I try to take it following this approach? Maybe I could start by defining the data structures and interfaces mentioned above.

[mengzhuo]

So, I think this feature can be implemented in this way initially:
First, we need to define a set of constants that represent each extension.
Then, we should create a new data structure called, for example, Extensions, which should expose interfaces like SetExtension and QueryExtension to allow for setting and querying. Internally, this data structure could be a bitmap or simply a hash map.
After that, the GORISCV64 parsing logic should parse the input string (formatted as something like rva23u64,extension1,extension2), call the SetExtension interface, and finally, the compiler logic would call QueryExtension to check for the extensions it needs and decide how to generate the code.

I'd like to ask if anyone has worked on this issue yet? If not, may I try to take it following this approach? Maybe I could start by defining the data structures and interfaces mentioned above.

@newborn22 This proposal is not been accept yet.

[mengzhuo]

It's too complicate for user to implement extension related code.

For example, chacha20 wants 2 vector related extension, but it will comes with a combinations.

• rva20u64,v
• rva20u64,v,zvkb
• rva22u64
• rva22u64,v
• rva22u64,v,zvkb
• rva23u64
• rva23u64,zvkb
• rva40u64 (if zvkb is mandatory)
• etc...

Which leads to many usage of it ( note profile can be compare with >= but not for build tag)

| Ext/Stage 	| filename 	| build cfg(SSA) 	| build tag (go file) 	| compile(asm) 	| runtime             	|
|-----------	|----------	|----------------	|---------------------	|--------------	|---------------------	|
| V         	| _?       	| goriscv >= 23  	| goriscv.rva23u64    	| hasV         	| cpu.RISCV64.HasV    	|
| Zvkb      	| _?       	| ?              	| ?                   	| hasZvkb      	| cpu.RISCV64.HasZVKB 	|

Maybe we should do it oppose, expand profile into extensions biset?

[Jorropo]

@mengzhuo you would write:

//go:build riscv64.V && riscv64.Zvkb

It is the go's toolchain job to follow the RISCV spec and set the v & zvkb bits if rva40u64 is set.

For build cfg we can codegen a package encoding this.
You would only need to write something like GORSICV.Has(riscvext.V | riscvext.Zvkb)

[markdryan]

Some comments and questions.

Who is this proposal targeted at? Who would actually build a go binary with GORISCV64=RVA20U64,Zacas? My understanding here is that people who are building and distributing binaries, i.e., the distros, will have to target one of the profiles, and so would not be able to take advantage of this proposal. For example, Ubuntu 25.10 targets RVA23U64 on riscv64, RockyLinux 10 targets rv64gc. They wouldn't be able to distribute a binary built with GORISCV64=RVA20U64,Zacas or GORISCV64=RVA23U64,Zacas.

I'm also concerned that there are too many RISC-V extensions to make a generic proposal like this practical. A reference was made above to the GOARM64 environment variable which allows additional extensions to be specified after the version number, but looking at the code I only see two permitted ARM64 extensions (lse and crypto). A quick (and probably inaccurate) survey of riscv-opcodes shows that there are 94 potential extensions we could use here, with more to come in the unratified folder. That's quite a lot of combinations. Would we permit all of them, or just a select few? How would we decide which ones to allow?

Regarding, Zabha and Zacas specifically, these are both development options in the RVA23U64 profile, which means that they are expected to become mandatory in a future RVA profile. We could just wait for the next major profile to be released before taking advantage of these extensions at compile time, although this is likely to be a few years away.

Also, I note that the ARM64 implementation of Cas has a runtime check for LSE (as well as a compile time check). We could add (and benchmark) a Cas implementation that uses Zacas with a runtime check, without a proposal.