proposal: all: create GOARCH=wasm64

[mf-RDP-two]

Proposal Details

Currently, there is #63131 (proposing a GOARCH=WASM32)

I see all internal compiler structures for SSA / codegen for wasm is in fact targeting 64bit already right now, effectively.
However, only 32bit output is implemented and there are i32.wrap_i64 for addresses, address locals are i32, etc.

IMO it would be very useful to implement wasm64 bit output now.
The feature has finally been standardized into the WASM spec!
https://github.com/WebAssembly/memory64
https://github.com/WebAssembly/proposals?tab=readme-ov-file

I only speak regarding the go compiler wasm output. As all needed infrastructure is already there, it should be a relatively small implementation, I guess.

Opinions?

[gabyhelp]

Related Issues

• cmd/compile: create GOARCH=wasm32 #63131

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

[cherrymui]

Thanks for filing the proposal.

Could you add more information about your use case?

Is the 64-bit runtime widely supported on various Wasm engines? E.g. browsers, node, wasmtime, wazero, etc..

As mentioned in #63131 (comment) , GOARCH=wasm64 is the plan for a full 64-bit Wasm port. The question is whether we want to do it now.

[mf-RDP-two]

cherrymui, thanks for your response.

use case: we use wasm64 for platform independent high performance computing, running on an own, proprietary JIT compiler and VM. the whole thing might come to the market next year. currently, it's targeting LLVM very strongly. but it would be great to have a reasonable go toolchain as well. gollvm/tinygo is not really an option as I don't trust it's compatibility too much.

for that, go compiler lacks currently two things:

1. wasm64 output
   (2.) DWARF generation (LLVM DWARF for wasm is great) - but I see this is likely more work and it is also not that important.

[aamironline]

For context, issue #65333 also depends on #63131, which is related to this issue (#75329). When are we expecting to close this?