Testsuite update
As a prerequisite of my current testsuite refactoring patch (!9515), I have put up a patch to ci-images (ci-images!114) to include necessary changes in the docker images we use in GHC CI. The testsuite driver now requires Python minimum version to be 3.7, but distro-provided Python version is too old in certain images (deb9/ubuntu18/centos/rocky), so I need to install up-to-date Python in those images, which will only be used to run the GHC testsuite driver and doesn’t interfere with system-wide Python installation.
During the ci-images work, I also opened a ticket #23186, the optllvm test way is often enabled even when not desired by the user. It’s a low priority bug that doesn’t block my current work.
The current ci-images patch is still pending review, but I’ve already tested it with a validate pipeline and a release pipeline for !9515 to ensure the refactored testsuite driver work in all CI docker images, and it indeed works. I’ve also cleaned up !9515 commit history, and did some fixes for previous test failures on other non-Linux platforms. The MR is green now, and the only remaining work is:
- Wait for the ci-images patch to land
- Fix the lint-testsuite warning, there are some mypy typing errors
- More detailed commit messages
!9515 has been a much deeper rabbit hole than I thought, though the hardest work has been done and I plan to land it asap. The patches that add necessary annotations in the testsuite scripts to disable broken tests and run the testsuite for wasm backend shall land in a subsequent MR.
Enabling wasm simd128 feature flag
Safari 16.4 has been released. Finally, the wasm simd128 feature is supported by default on latest versions of all major browser engines plus wasmtime. I have proceeded to enable the wasm simd128 feature flag by default in our C/C++ builds. If you use wasm2wat or wasm-objdump to inspect the output of GHC wasm backend shipped by latest ghc-wasm-meta, you can see that there are already v128 opcodes in the wasm module, which is the result of clang compiler optimization.
To improve the production readiness of wasm simd128, I put up a patch to wizer (#69) that implements simd128 support. It’s pending upstream review now, but the wizer copy we ship in ghc-wasm-meta already includes this patch. I also filed yet another LLVM ticket (#61773): the wasm assembler doesn’t support v128 global definitions, though this one is also low priority and doesn’t block my work.
There are multiple potential future works that can be done to better make use of simd128:
- Add wasm simd128 support in simdutf, and enable text simdutf flag by default when building the GHC wasm backend. This will improve performance in workloads that involve a lot of UTF-8 validation using the text package.
- Add simple v128 load/store opcodes support in the GHC wasm backend’s native codegen. They can be used to efficiently inline call sites of memcpy/memmove/memset Cmm primops when the buffer size is a small known integer.
- Support GHC’s own simd primops in the wasm backend’s native codegen. It’s straightforward but requires a lot of work.