proposal: math: add math_pure_go flag to avoid assembly code

[0x1cc]

Introduction

In the current Go math package, when the architecture has a Floating-Point Unit (FPU), it accelerates floating-point computations using assembly code tailored to take advantage of the architecture's FPU. While this approach offers excellent performance, it creates compatibility issues with softfloat. To support softfloat, we can use -gcflags=all=-d=softfloat, which can convert floating-point calculations to softfloat within the compiler, but it doesn't impact any assembly code in the math package. (The related issue can be found here: [link to GitHub issue #62470].)

To address this issue, we propose introducing a new build tag that disables the math package from utilizing FPU-related assembly code for performance optimization, thereby providing support for softfloat.

Proposed Solution

To support softfloat in the Go math package, we propose adding a new build tag, let's call it math_pure_go, that users can apply to disable the use of FPU-specific assembly code in the math package. We can use the math_pure_go build tag to disable the assembly in math package. With the build tag -tags=math_pure_go and -gcflags=all=-d=softfloat, we can support softfloat for all platforms.

go build -gcflags=all=-d=softfloat -tags=math_pure_go

Benefit

• This enhancement will make the Go math package compatible with softfloat, allowing Go to be used in environments or on architectures where hardware FPU support is not available or desired.
• Users who require softfloat support will be able to utilize the math package without encountering compatibility issues.
• The softfloat support is necessary in many scenarios, such as blockchain and cryptographic technologyies.
  • In blockchain technology, where determinism and consistency are critical, using softfloat ensures consistent results across various platforms. This is crucial for achieving consensus among nodes in a decentralized network.
  • Zero-knowledge proofs are cryptographic techniques that rely on precise and consistent mathematical operations. Softfloat support is essential for achieving consistent and predictable results when implementing zero-knowledge proof systems.
• The proposal aligns with Go's philosophy of providing flexibility and compatibility across various platforms and use cases.

[0x1cc]

The implementation for softfloat support in the math package can be found in this pull request: GitHub Pull Request #63271.

[mvdan]

What about the existing purego tag? #23172 cc @dsnet

[bcmills]

While this approach offers excellent performance, it creates compatibility issues with softfloat.

We already have GOMIPS=softfloat, GO386=softfloat, etc. for specifying the use of softfloat implementations on specific platforms — it seems like a mistake to add yet another (orthogonal) way to specify that.

If softfloat support is really needed on WASM platforms, adding a GOWASM=softfloat seems like it would be a cleaner approach.

[FiloSottile]

This should be fixable without a proposal by just adding purego support per #23172. It has other advantages, such as supporting other compilers. TinyGo is currently having to alias symbols in the math package:

https://github.com/tinygo-org/tinygo/blob/731532cd2b6353b60b443343b51296ec0fafae09/compiler/alias.go#L27-L31

[leongross]

Are there still ongoing efforts on this topic? PR #23172 still seems to use the earlier proposed math_pure_go which is different to pure_go.
What are the blockers here exactly? I would be glad to assist since I'm working on tinygo as well and would profit from this implementation.

[ianlancetaylor]

I don't see a problem with using the existing purego build tag to disable assembler code in the math package. I don't think there any blockers, but somebody has to write and test the patch.