proposal: runtime: softfloat for RISCV target

[kevaundray]

Proposal Details

Proposal

Although the compiler is supposed to support RVA20U64, it is possible to use d=softfloat to remove pure go floating operations. This does not transform the assembly generated floating point code.

Could we have the same treatment for RISCV as it is for mips for targets that do not have a FPU?

Related issue:

#32760

[gabyhelp]

Related Issues

• change GORISCV64=rva20u64 to include compressed instructions #71105

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

[seankhliao]

cc @golang/riscv64

[mengzhuo]

The minimal requirement for riscv64 is "g" which includes "fd".
https://go.dev/wiki/MinimumRequirements#riscv64

And I quoted from #32760

Thanks for the explanation. I can see how it makes this very special use case a bit easier but I do not think there is sufficient demand to out way the complexity and maintenance burden that would be added.

[kevaundray]

The minimal requirement for riscv64 is "g" which includes "fd".
https://go.dev/wiki/MinimumRequirements#riscv64

And I quoted from #32760

Thanks for the explanation. I can see how it makes this very special use case a bit easier but I do not think there is sufficient demand to out way the complexity and maintenance burden that would be added.

I agree that with the softfloat flag, it would mean that the target would change to ima (and now c since that PR was merged recently)

The reference post was from six years ago, could you say more about the maintenance burden that this would add?

[mengzhuo]

The minimal requirement for riscv64 is "g" which includes "fd".
https://go.dev/wiki/MinimumRequirements#riscv64
And I quoted from #32760

Thanks for the explanation. I can see how it makes this very special use case a bit easier but I do not think there is sufficient demand to out way the complexity and maintenance burden that would be added.

I agree that with the softfloat flag, it would mean that the target would change to ima (and now c since that PR was merged recently)

The reference post was from six years ago, could you say more about the maintenance burden that this would add?

It's not my priority task for now, I think you can join the RISE-Go-runtime monthly meeting and state more about your proposal by contact @markdryan . Maybe RISE will send your proposal to someone whom has interested in.

Some of works that I come up with in 1 min:

1. riscv64 related flag only controls profile (an integer) and asm/runtime/compiler rely on this flag heavily
2. ABIinternal has to change into FP reg free version.
3. The codegen test has to add FP reg free cases
4. Generate proper attributes that didn't comes with "fd" in every types of blob (exec/plugin/c-archive etc,.)

Not to mention we had to setup at least 2 builders to verify everything is fine.

[kevaundray]

The minimal requirement for riscv64 is "g" which includes "fd".
https://go.dev/wiki/MinimumRequirements#riscv64
And I quoted from #32760

Thanks for the explanation. I can see how it makes this very special use case a bit easier but I do not think there is sufficient demand to out way the complexity and maintenance burden that would be added.

I agree that with the softfloat flag, it would mean that the target would change to ima (and now c since that PR was merged recently)
The reference post was from six years ago, could you say more about the maintenance burden that this would add?

It's not my priority task for now, I think you can join the RISE-Go-runtime monthly meeting and state more about your proposal by contact @markdryan . Maybe RISE will send your proposal to someone whom has interested in.

Some of works that I come up with in 1 min:

1. riscv64 related flag only controls profile (an integer) and asm/runtime/compiler rely on this flag heavily
2. ABIinternal has to change into FP reg free version.
3. The codegen test has to add FP reg free cases
4. Generate proper attributes that didn't comes with "fd" in every types of blob (exec/plugin/c-archive etc,.)

Not to mention we had to setup at least 2 builders to verify everything is fine.

Thanks -- yes, it would be great to get a invite to the monthly meeting

[4a6f656c]

The initial target for RISC-V was always rv64g as a minimum - that's since moved to rva20u64.

While it is theoretically possible to support softfloat, it does not really serve a significant benefit, creates extra work/effort to maintain and is generally the opposite direction of where Go on RISC-V is heading.

[kevaundray]

The initial target for RISC-V was always rv64g as a minimum - that's since moved to rva20u64.

While it is theoretically possible to support softfloat, it does not really serve a significant benefit, creates extra work/effort to maintain and is generally the opposite direction of where Go on RISC-V is heading.

One benefit of supporting softfloat which seems to be inline with one of golang's goals, is to make ports of golang easier to maintain -- in particular, ports that want to support bare metal targets where FPU is not a given.

My reference for thinking that making ports of Golang easier, came from comments in the past given by @ianlancetaylor and @rsc :

• proposal: all: add bare metal ARM support #37503 (comment)
• proposal: all: add bare metal ARM support #37503 (comment)

Let me know if this has changed or whether this would fall outside of that scope for RISCV

[4a6f656c]

The initial target for RISC-V was always rv64g as a minimum - that's since moved to rva20u64.
While it is theoretically possible to support softfloat, it does not really serve a significant benefit, creates extra work/effort to maintain and is generally the opposite direction of where Go on RISC-V is heading.

One benefit of supporting softfloat which seems to be inline with one of golang's goals, is to make ports of golang easier to maintain -- in particular, ports that want to support bare metal targets where FPU is not a given.

I don't believe this is an accurate interpretation -- if there are ways that out of tree ports can be made easier to maintain, while not creating additional maintenance burden, then that's fine, but in this case that does not really hold true. In fact rsc's decline comment is more applicable - "the cost is high and the benefit is low".