Proposal Details
When the proposal for GORISCV64 was being discussed, the situation regarding compressed instructions for RISC-V was somewhat unclear and there were discussions about potentially reusing the encoding space. As such, the decision was to make the default GORISCV64 value be rva20u64 but explicitly exclude compressed instructions, effectively giving rv64g:
https://github.com/golang/go/issues/61476#issuecomment-1782053089
There has since been a decision regarding the future of the C extension, with it remaining a mandatory part of RVA20 and RVA22:
https://lists.riscv.org/g/tech-profiles/topic/rvi_bod_decision_regarding/102522954
This means that all general purpose RISC-V hardware that Go will run on must support compressed instructions.
This proposal is to change Go's meaning of GORISCV64=rva20u64 to include compressed instructions, instead of continuing to prohibit them.
Comment From: 4a6f656c
/cc @markdryan
Comment From: gabyhelp
Related Issues
Related Code Changes
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: gopherbot
Change https://go.dev/cl/523477 mentions this issue: cmd/internal/obj/riscv: add support for compressed instructions
Comment From: gopherbot
Change https://go.dev/cl/523478 mentions this issue: cmd/compile/internal/riscv64: use CNOP for compiler inserted NOPs
Comment From: gopherbot
Change https://go.dev/cl/523476 mentions this issue: cmd/internal/obj/riscv: add encoding for compressed riscv64 instructions
Comment From: gopherbot
Change https://go.dev/cl/639656 mentions this issue: cmd/obj/riscv: add support for the Compressed extension
Comment From: gopherbot
Change https://go.dev/cl/639657 mentions this issue: cmd/obj/riscv: compress ADD instructions
Comment From: gopherbot
Change https://go.dev/cl/639658 mentions this issue: cmd/obj/riscv: compress NOP instructions
Comment From: ianlancetaylor
CC @golang/riscv64
Comment From: markdryan
I'd previously +1'ed this proposal but thought it best to also add my support with some actual words.
All current riscv64 devices support the compressed instruction set. We now know that all future riscv64 devices supporting a standard profile will also have compressed instructions. Compressed instructions consume 75% of the current RISC-V instruction encoding space, so it's a real waste not to use them. The use of compressed instructions in Go should reduce binary size and improve instruction cache utilisation. To quote from the The RISC-V Instruction Set Manual Volume I (Version 20240411)
The philosophy of RVC is to reduce code size for embedded applications and to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size.
Note that we have had some compressed instruction patches pending for quite a while. These patches were put on hold when there was some doubt about the future of compressed instructions in the standard RISC-V profiles, e.g.,
https://go-review.googlesource.com/c/go/+/523477/3
If you look at the comments of this and other related PRs, you will see Russ Cox wrote
This would require compressed instruction support in the riscv port, so we need an accepted proposal for that.
This is the requested proposal to add their support to Go and unblock the pending patches.
Comment From: glycerine
This proposal is to change Go's meaning of GORISCV64=rva20u64 to include compressed instructions, instead of continuing to prohibit them.
Is this proposal controversial because it changes the meaning of an existing name, in opposition to the naming principles uses in Go packages?
If so, why not just give it a different, new, unique name?
Sure, that means the compiler must support both using and not using the C extension compressed instructions for the time being, which is a maintainence burden... but maybe that will get this proposal unstuck and moving forward...? The existing name rva20u64 could be marked deprecated?
Comment From: Jorropo
Mostly because why create an other thing if we don't have to ? ¯\_(ツ)_/¯ No one pointed out problems with this proposal for yet.
We think the reasons* this decision was made at the time are no longer a concern.
Overall it is confusing for rva20u64 to mean something different in Go than in the rest of the riscv ecosystem, it made sense at the time, but I don't see how committing to something let's say rva20u64,c is not confusing so we better have a good reason to take that route.
*see the messages from @markdryan and @4a6f656c
Comment From: mengzhuo
As a member of the @golang/riscv64 , I support this proposal, while noting the concerns raised about changing the meaning of rva64u20. I believe that aligning Go’s riscv64 support with the current hardware ecosystem is important for the community and AFAIK only Go plugin affected by this change.
Comment From: markdryan
We think the reasons* this decision was made at the time are no longer a concern. Overall it is confusing for rva20u64 to mean something different in Go than in the rest of the riscv ecosystem, it made sense at the time, but I don't see how committing to something let's say rva20u64,c is not confusing so we better have a good reason to take that route.
Agreed.
Also, I will just stress that there is nothing controversial today about generating compressed instructions when the RVA20U64 (or RVA22U6 or RVA23U64) profiles are targeted. Compressed instructions are a mandatory part of each of these profiles, as can be seen here. The fate of the compressed instruction set was in doubt back when we added RISC-V profile support to the Go tool chain, so we decided to delay their implementation and wait to see what happened. Now that their fate is secured we can safely go ahead and implement them.
So if there's nothing controversial about these instructions why do we need a proposal? We probably don't. I think all we need to do is to agree that the comments relating to compressed instructions made on the compressed instruction patches and in the original profiles proposal are no longer relevant, given that the compressed instruction set's place in the RISC-V profiles is now guaranteed. Once we've done that we can remove the hold from the patches and complete the implementation.
Comment From: kevaundray
Currently I'm building for an environment where we don't need/want the compressed instruction set, so would be great if there was a way to always compile with just riscv64g
Comment From: Jorropo
This is not a currently supported use-case since by definition it wouldn't implement the minimum baseline of rva20u64.
I would open a new proposal about this.
Comment From: aclements
This proposal has been added to the active column of the proposals project and will now be reviewed at the weekly proposal review meetings. — aclements for the proposal review group