Add weval support to PBL.

[cfallin]

This PR modifies the main PBL interpreter to support specialization by partial evaluation using the weval tool 1, producing compiled functions for JS function bodies and IC bodies.

Because partial evaluation allows us to reuse the interpreter body as the definition of the compiler output, the changes are fairly self-contained: we "register" the "specialization requests" to create new functions from the combination of the interpreter and some bytecode, and we use that specialized function when it exists.

As an optimization, we also modify the macros used in the interpreter body to make use of some weval intrinsics, allowing weval to more efficiently support the operand stack and some other details. These optimizations are unnecessary for correctness, but provide much better performance in some cases.

This PR, when used to perform ahead-of-time compilation, provides quite significant speedups over interpreted PBL:

              generic interp  old PBL     new PBL   wevaled PBL (this PR)
Richards        166             214         263       729
DeltaBlue       169             254         287       686
Crypto          412             456         410      1255
RayTrace        525             660         761      1315
EarleyBoyer     728             941        1227      2561
RegExp          271             301         358       461
Splay          1262            1664        1889      3258
NavierStokes    656             623         601      2255
PdfJS          2182            2055        2423      5991
Mandreel        166             189         211       503
Gameboy        1357            1548        1552      4659
CodeLoad      19417           18644       17350     17488
Box2D           927             995         978      3745
----
Geomean         821             943        1039      2273

[JakeChampion]

I configured this repo to run the github workflows (they were disabled for some reason) and now we have our automated tests running again 🥳

[cfallin]

Rebased and ready for review!

[cfallin]

the intermittent jit-test failure from #47 is back; I still can't reproduce locally, even in a loop trying to hit any nondeterministic issues. I've pushed a commit to disable the gc/bug-1791975.js jit-test under PBL for now; it has to do with OOM, incremental GC (which we don't make use of in single-threaded Wasm builds), and the original patch that it's testing doesn't seem to touch anything that PBL does. It's always possible I'm missing something here but in the meantime the risk seems low to me...

[kungfooman]

I just read your blog post at https://cfallin.org/blog/2024/08/27/aot-js/

It sounds like I can just take any JS project and convert it to WASM for a possible speed increase. Is this true and are there any more specific instructions to use this tech for projects?

[cfallin]

@kungfooman with a lot of nuances:

• This is applicable in a context where one is running JS in a Wasm module outside the web already (e.g., server-side Wasm, or plugin Wasm, on a WASI platform), where the state of the art today is running a JS interpreter. If you have "web JS", this isn't applicable.
• This has been integrated into StarlingMonkey, Bytecode Alliance's JS runtime built around SpiderMonkey for such use-cases. There, the --aot flag to componentize.sh invokes the compilation flow.
• This is definitely not a supported product on its own today, outside of the contexts in which it's been integrated. It's more in a "play with it if you know what you're doing" state, with slow rollout in more specific contexts.