Took some time off last week, and this week is a rather slow one due to lots of reasons. Still, glad I have some progress to report:
Testsuite update
Finally some good news here! I’ve finished all testsuite driver refactorings that gets rid of multi-threading logic completely in favor of coroutines & asyncio. The driver is now able to run the full testsuite for the wasm backend under normal speed without getting stuck mysteriously.
There are about 100 remaining unexpected failures that needs triaging:
- Boring failures that can be fixed by enhancing the driver to take cross compilation more seriously, e.g. handling target platform prefix and executable extensions properly
- Boring failures which will be marked as expect_broken because they use features unsupported by wasm32-wasi
- Several interesting failures that each has its own tracking issue. They aren’t high priority like the codegen bugs I previously fixed, and fixing them require more time, so we’ll prioritize getting the entire testsuite running on CI first, then revisit these failures afterwards.
Enabling wasm multi-value feature flag
As documented in ghc-wasm-meta, the GHC wasm backend emits wasm modules that make use of certain post-MVP features. Once a feature has been supported by default in latest versions of major browser engines plus wasmtime, I will make use of it. Even if it’s not immediately used by the wasm backend native codegen, I can still enable it when compiling C/C++, to enable better compiler optimization.
The wasm multi-value feature has been widely supported for quite a while. However we’ve refrained from using it, given there were certain LLVM bugs when multi-value is enabled everywhere (#55136) (#59095). Just recently, @HerrCai0907 kindly fixed the last known multi-value bug (#59095) and I’ve tested that the fixes work perfectly. So finally, we’re able to flip on the multi-value feature flag in our builds.
Enabling multi-value benefits C code that uses 128-bit integers & long doubles, since they can now be directly passed without involving the C stack. It’s a tiny but non-zero optimization opportunity. Later, after there is proper testing & benchmarking setup for the wasm backend, I may experiment with alternative calling conventions that make use of wasm multi-value, and see if there can be performance benefits.
Misc other work
- I’ve confirmed that I’ll be presenting at this year’s GHC contributors’ workshop prior to Zurihac. There will be a wasm backend session, which I’ll give a talk to introduce its internals, and help new contributors who are interested in hacking it. On-site participation of the workshop is limited, though the talk recording will be released, and there’s even more space & time to work on it after Zurihac starts. See you in June!
- Our binaryen builds are now linked against mimalloc, which improve wasm-opt performance, especially on many-cores machines (#5561).