proposal: cmd/compile: add support for RISC-V B-extension

[benshi001]

The specification of bitmanip instructions became stable from draft: https://github.com/riscv/riscv-bitmanip

So I propose to support these instructions, which could make following benefits.

1. Accelerate several math.bits functions, such as bits.CountLeadingZeros
2. Accelerate logal and/ori/xori, for example, "x=x&0xfffeffff" can be simplifed to a single instruction "bclri $16, Reg"
3. integer extension can be simplifed with a single "bext" from current pari of arithmetic left/right shift.
4. others

However, there is no real world hardware support them now, but we can implement them in the assmbler by now.

One concern, Go's riscv64 implies the i-a-m-f-d extensions (also known as rv64g ), do we need something like GORISCV64=GB to enable the B-extension instrutions?

[randall77]

Supporting assembly seems fine.

One concern, Go's riscv64 implies the i-a-m-f-d extensions (also known as rv64g ), do we need something like GORISCV64=GB to enable the B-extension instrutions?

Where are the minimum extensions for riscv64 specified? I don't see an entry in https://github.com/golang/go/wiki/MinimumRequirements . Could you add an entry?

Yes, we can't use B extension instructions in the compiler without introducing a GORISCV64 environment variable or guarding them at runtime.
For 1, it's probably worth it to use them with a runtime guard. We do that for popcount on amd64, for example.
The other two probably aren't better enough than their non-B equivalents to warrant a runtime guard. And I don't think they are in total better enough to warrant a GORISCV64 modifier. But that's a guess, actual benchmarks would be helpful once hardware exists.

[benshi001]

Supporting assembly seems fine.

One concern, Go's riscv64 implies the i-a-m-f-d extensions (also known as rv64g ), do we need something like GORISCV64=GB to enable the B-extension instrutions?

Where are the minimum extensions for riscv64 specified? I don't see an entry in https://github.com/golang/go/wiki/MinimumRequirements . Could you add an entry?

I have added, that the minimal requirement is rv64g (rv64imafd).

Yes, we can't use B extension instructions in the compiler without introducing a GORISCV64 environment variable or guarding them at runtime.
For 1, it's probably worth it to use them with a runtime guard. We do that for popcount on amd64, for example.
The other two probably aren't better enough than their non-B equivalents to warrant a runtime guard. And I don't think they are in total better enough to warrant a GORISCV64 modifier. But that's a guess, actual benchmarks would be helpful once hardware exists.

I suggest using a GORISCV64 environment, and gcc/clang use the command line option -march to indicate instruction set.

[benshi001]

One more reason for support a GORISCV64 env-var, is that there might be rv64 machines without a HW floating point unit. All FP calculation must be implemented via software functions.

For example, we reqiure the minimal should be I-M-A, and F-D-B-V-P are optional. So the GORISCV64 is a combination of F-D-B-V-P with a prefix IMA.

[mengzhuo]

I think we should detect extension in runtime cpu feature detection.

[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

[4a6f656c]

While there is no significant downside to adding support for these instructions in the assembler, I also think there is benefit in waiting until there is actual hardware support for them. Furthermore, we should be confirming that the use of these instructions is actually providing benefit, which means we need to be able to benchmark.

IMO as far as possible we should avoid compile time options and perform runtime detection - I've seen various problems with compile time options (like GOARM and GO386), particularly with binary packaging. While you may be building on a machine that supports one feature set, you end up having to opt for the lowest common denominator as the packages may be installed on a machine that does not support it.

Lastly, the current Go riscv64 port currently targets rv64g (which is effectively a baseline for most real world RISC-V hardware) - I would be very reluctant to remove F and D and require those to be explicitly turned back on (largely for the same reasons as mentioned above) - additionally removing these from the minimal target is going to create additional maintenance and require additional testing for the port.

[rsc]

It sounds like we should decline this issue until there is actual hardware that we can use to measure the impact of B.

There was a suggestion above to lower the current minimum feature set, removing F and D. That is a separate discussion, and if you feel strongly about that, I would suggest filing a separate proposal.

[rsc]

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