91ESR with Baseline Compiler/Baseline wasm for POWER9

It's heeeeeee-re. I've completed the pull-up of the POWER9 Firefox JavaScript JIT to the current ESR, Firefox 91. As a bonus I also completed the second-stage Baseline Compiler (Baseline Interpreter being the first-stage compiler) at the same time for a reason I'll explain in a minute.

The build process is the same as Firefox 91, using the 91ESR tree, but requires adding --enable-jit to your .mozconfig and applying this patch and set of files. Please note that POWER9 remains the only supported architecture (Power10 grudgingly, but it should work), and only on little-endian. If you compile big-endian, the JIT should statically disable itself, even with --enable-jit. If you compile with -mcpu=power9, which is recommended, the JIT is statically enabled with --enable-jit and becomes slightly faster because there are fewer runtime checks. If you don't explicitly specify POWER9, or do something like -mcpu=power8, but still specify --enable-jit, then runtime detection should be enabled (which right now disables the JIT). I have not tested this on POWER8 because I don't have a POWER8, so I can't fix it myself. If this doesn't work or builds a defective Firefox or JavaScript shell, please submit a correction and I'll incorporate it.

What's working? What now works is the Baseline Interpreter and the Baseline Compiler, and Baseline compilation for Web Assembly. asm.js using Cranelift isn't supported yet, because this requires the third-stage Ion optimizing compiler, and WebAssembly transpiled to asm.js will simply compile in Baseline. This is not the fastest the browser can run, but it is certainly noticeably faster, and most of the pure JavaScript benchmarks I tested showed it is already several times more efficient than the C++ interpreter. I did not encounter any obvious crashes in things like Gmail, Google Docs and my workplace Office 365 instance (and I was a lot more productive!) but the reason for releasing this is to see if you find any. If you can reliably crash the browser in a way that doesn't crash with the JIT off, file an issue with exact steps to reproduce. If I can't reproduce it, I can't fix it. Steps to trigger an assertion in a debug build would be even more helpful.

What's not working yet? The third-stage optimizing compiler doesn't work and isn't enabled (our patches turn it off by default in the browser, and you should always specify --no-ion to the JS shell unless you're doing development), and as stated, this also means no specific Cranelift support for things like the asm.js-based DOSBox and MAME emulators on Internet Archive. These will run in the slower Baseline Compiler directly. There are also some failures in Wasm compared to x86_64 and ARM that didn't turn up in the test suite (it passes everything) which I'm unable to narrow down right now. For example, WAD Commander has graphical glitches even though the game plays fine, and Google Earth stalls out with a runtime error. The reason I finished the Baseline Compiler support was on the hopes I'd smoke out some other bugs, and I did in fact find more to fix but it didn't fix these. On the other hand, these handcoded Wasm demos seem to work, as does this Wasm RISC-V emulator, this somewhat funky karts game and this Wasm Gameboy emulator:

It is entirely possible that some of this is simply due to other pre-existing bugs on our platform that this support just unmasks — after all, we were never able to run code like this before — and there are naturally changes in later Firefoxen that aren't in the ESR. I won't be able to assess that until it's pulled up further, of course, but for the time being you can use the JIT in 91ESR if you prefer/need the speed while further development stabilizes. Until then, please don't file issues on Wasm stuff that doesn't work unless you know why it doesn't work.

Next steps? The plan is to pull the 91ESR JIT up to Firefox 97 or 98 alpha and start on Ion development on that new base hopefully finishing in time to do one last pull-up to Firefox 102, i.e., the next ESR, and submit the finished JIT to Mozilla then. Longer term, we'd welcome support for additional configurations and the key is SupportsFloatingPoint() in js/src/jit/ppc64/Assembler-ppc64.h, which I have abused as a runtime gate. You should be able to tell from the comments in that file how to force the JIT to run on an unsupported configuration. I have implemented HasPPCISA3() which returns true on POWER9 (and Power10) so that appropriate codegen paths are run based on the CPU present. Most of the codegen will work on little-endian POWER8 except for a few places that will hit a forced crash. If you get this working and implement HasPPCISA27() or some such, then I will accept those changes assuming they are not massive. I will also accept big-endian patches, but you will have a much bigger job, and unless you're prepared to do little-endian emulation for Wasm or asm.js (like the limited little-endian support in TenFourFox's IonPower-NVLE for typed arrays) and maintain those changes certain things will never work on big.

Meanwhile, your contributions are still solicited especially on the new work to be done and we'll be getting that new tree up so you can participate. However, patches and PRs that will not be accepted are anything that regresses the core support for LE POWER9, spacing or style changes (we will be doing cleanup on the entire set before submitting to Mozilla, so please don't waste our time on this right now), or sets covering multiple issues (one catastrophe at a time, please). The faster we get this done, the faster we get it in the tree, and the better supported we'll be going forward.

Starting with Firefox 96, there will be the usual updates on building mozilla-release, but I'll also do a verification build on 91ESR and make any needed updates to patches, and upload updates to Github. Please post your constructive and reproducible issues in the comments or on Github for triage.