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.