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:

https://github.com/golang/go/issues/32760

Comment From: gabyhelp

Related Issues

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

Comment From: seankhliao

cc @golang/riscv64

Comment From: 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.

Comment From: 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?

Comment From: 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.

Comment From: 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

Comment From: 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.

Comment From: 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 :

  • https://github.com/golang/go/issues/37503#issuecomment-611859305
  • https://github.com/golang/go/issues/37503#issuecomment-624778703

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