For the past few weeks I've been working on a Wasm to Go <https://github.com/ncruces/wasm2go> translator. It takes a Wasm module and converts it to a Go package. I plan to use it for my SQLite driver. I'm translating a Wasm build of SQLite into ~ 600 kLoC of Go <https://github.com/ncruces/go-sqlite3-wasm>. I've tested it across 20 GOOS/GOARCH combinations.
I have found that GC produces suboptimal code in some situations. Wasm is a little endian platform, so a memory load is something like (offset is a constant literal): int32(binary.LittleEndian.Uint32(m.Memory[int64(ptr)+offset:])) I've noticed that, on little endian platforms, this works much faster: *(*int32)(unsafe.Pointer((*[4]byte)(m.Memory[int64(ptr)+offset:]))) I think because the first version has 2 bounds checks, and the later just one? This is unfortunate, as I have to generate 2 versions of the code (for little and big endian). Am I missing any trick to get the compiler to generate better code? Thanks! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/2bffffa0-e64d-4014-95e9-b15fe4961a63n%40googlegroups.com.
