proposal: softfloat support for GOARCH=wasm

[qizhou]

We are working on proving the execution of go-compiled WASM code using zero-knowledge (ZK) (see https://github.com/DelphinusLab/zkWasm). However, the current zkWASM prover cannot support floating point instructions (f32.xxx/f64.xxx). We tried to use go build -gcflags=all=-d=softfloat and we found most of the FP instructions are translated to INT ones except f64.load, f64.store, f64.ceil, f64.floor.

Q: Is there a way to support softfloat explicitly for WASM or any flags to fully support softfloat?

Test code (fp.go):

import "math"

func main() {
	a := 3.5
	b := 2.7
	println(math.Ceil(a))
	println(math.Floor(a))
	println(a / b)
}

Commands

$ go version
go version go1.21.0 linux/amd64
$ GOOS=js GOARCH=wasm go build -gcflags=all=-d=softfloat fp.go
$ wasm2wat fp | grep 'f32\.'
$ wasm2wat fp | grep 'f64\.'
    f64.load offset=8
    f64.floor
    f64.store offset=16
    f64.load offset=8
    f64.ceil
    f64.store offset=16

[ianlancetaylor]

CC @golang/wasm

[ianlancetaylor]

This would presumably need to be an option in the GOWASM environment variable.

[johanbrandhorst]

Have we introduced a GOWASM variable or are you proposing a new variable?

[rsc]

It seems truly ironic for a WASM implementation not to support floating point.

[qizhou]

It seems truly ironic for a WASM implementation not to support floating point.

ZK technology that supports floating point instructions is much harder than integer ones - especially since most ZK/blockchain applications use high-resolution integers (mostly 256-bit) to perform financial applications such as balance transfer, token swap, compound rate, etc.

[LiuJiazheng]

Hi there, I am working with @qizhou trying to deliver a provable WASM program. It would be greatly appreciated if we could be guided the pointers or links which implement f32/f64 as software float simulation (i.e. how the softfloat takes effect, it seems right now that the support is partially), thus we might do some handcraft change ourselves : )

[LiuJiazheng]

Plus can confirm f32 is gone after using -d=softfloat
fp.go

func main() {
        a := float32(3.5)
        b := float32(2.7)
        println(a / b)
}

commands

% env GO111MODULE=on GOOS=wasip1 GOARCH=wasm go build -gcflags=all=-d=softfloat fp.go
% wasmtime fp
+1.296296e+000
% wasm2wat fp | grep 'f32\.' | wc -l
       0
% wasm2wat fp | grep 'f64\.' | wc -l
       0

[0x1cc]

I think this is a problem caused by the incompatibility of the math library with the softfloat compilation option. Take math.Floor in (src/math/floor.go) as an example.

// src/math/floor.go Line 14

func Floor(x float64) float64 {
	if haveArchFloor {
		return archFloor(x)
	}
	return floor(x)
}

When the compilation architecture is WASM , it will directly uses the corresponding underlying instructions of WASM (src/math/floor_wasm.s). Therefore, softfloat does not work!

// src/math/floor_asm.go

//go:build 386 || amd64 || arm64 || ppc64 || ppc64le || s390x || wasm

package math

const haveArchFloor = true

[LiuJiazheng]

Okay now it looks more like a bug to me.

Is there a way to pass the gcflag into math package in runtime? Or a build flag could help this.

[randall77]

-gcflags=all=-d=softfloat only affects the compiler (gc = Go Compiler). It does not affect any assembly code in the math package or elsewhere. Thus it isn't the equivalent of a GOWASM=softfloat build option.

[LiuJiazheng]

@randall77 Thanks. That makes sense.
I agree the proposal of adding GOWASM=softfloat would be an elegant way to implement that.

go/src/internal/buildcfg/cfg.go

Line 137 in 0613896

func gowasm() (f gowasmFeatures) {