IonMonkey PPC backend

[GoogleCodeExporter]

from dvander to m.dev.tech.js-engine today,

IonMonkey has now landed on mozilla-central (yay!). Largely this shouldn't 
affect anyone doing SpiderMonkey development, but in case it does, here are the 
big takeaway changes:

(0) Benchmarks (usually) get faster. Compiling the shell does not. Sorry :(

(1) By running the shell, the flags "--ion -m -n" are now implied by default. 
You can disable them respectively with "--no-ion", "--no-jm", and "--no-ti". 
Disabling TI disables IonMonkey.

In the browser, there is one new JS pref: "javascript.options.ion.content". We 
don't expose any other flags since they'd only exist to horribly break stuff.

(2) IonMonkey, unlike JM, does not use the interpreter stack to store local 
variables and frames. It uses the C stack. This means that cx->fp(), 
js_GetTopStackFrame(), etc, must not be used unless with great care. Even if 
you have a js::StackFrame, it is not okay to peek at it because it could be 
stale.

When in doubt, use the wonderful ScriptFrameIter class. It has abstractions for 
walking the stack and inspecting frames so you don't ever have to touch a 
js::StackFrame.

(3) Lastly, IonMonkey introduces new ways to get in and out of the JIT. 
Briefly, they are:

  (a) At function calls or loop edges, we may decide to run a script with IonMonkey. From C++, this goes through ion::Cannon.

  (b) A guard failure, type-inference invalidation, or GC can cause a "bailout". A bailout is when an Ion frame on the stack must be converted back into an interpreter frame. When this happens, interpreter frames are created for each JS frame in the Ion frame (there can be multiple because of inlining), and we resume running the function in the interpreter instead.

-David 

The stack frame stuff could be ... very interesting given our past 
misadventures with stack. For Judgment Day, we will simply disable it, but we 
should start working on it.

Original issue reported on code.google.com by classi...@floodgap.com on 11 Sep 2012 at 8:32

• Blocked on: JM backend to be fully ABI-compliant (prerequisite for IonMonkey) #179, Fix multithreading in JavaScript #219, Implement BaselineCompiler #224, Implement PPCBC: optimize the shizznick out of BaselineCompiler #245

[shawnl]

Any chance of this work going into mozilla-central to support Linux-ppc64le?

[classilla]

You're welcome to move the code over, but it won't be me that does it, since I don't have a Power8 or interest in that specific platform currently. If you wanted to do so, you would need to change the code that patches Ion for big-endianness (probably simply revert those changes), make sure the PPC backend was little-endian as well (we essentially assumed big-endian), finish the asm.js work which I abandoned for lack of utility, and change the trampoline for SysV ABI (OS X/ppc is PowerOpen, same as AIX). This is not trivial work, but you're welcome to try.

[shawnl]

but it won't be me that does it

Appears you changed your mind :)
http://tenfourfox.blogspot.com/2017/08/and-now-for-several-things-that-are.html

[awilfox]

I'm seriously hoping that a Linux PPC BE backend makes it, too, because some of us are running Taloses (and other post-G5 POWER hardware) in BE mode...

[yhaenggi]

That would even be good for G4/G5's running linux.

[classilla]

The JIT I'm planning to write unfortunately won't address either of those cases; it will be a 64-bit ("nunbox") little-endian JIT for POWER9, since that's how I run my own Talos. The folks working on a Chromium port are also running the JIT in LE.

It would still be possible to get a BE JIT working, but you'd still need to hack the core JIT to get around certain glitches with slot ordering (the 64-bit version may be better in this regard) and to get Wasm up you'll have to go whole hog and byteswap everything to and from typed arrays. TenFourFox only does this for integers since there are specific instructions that let us do that with no penalty. FPRs would have to be spilled and reordered. It would suck, but Wasm code tends to be inherently little-endian since most of it is being built on those platforms.

You could crib some of the patches from here (look for #ifdef JS_CPU_PPC_OSX and #ifdef JS_CODEGEN_PPC_OSX) but it would need to be adapted for what they're doing now.

[classilla]

I should add that it would be easier on Firefox than Chromium. Firefox at least assumes a lot less about the endianness of the machine, whereas I don't believe Chromium has ever run on a BE platform.

[awilfox]

At this point, the Web is crippled on PowerPC due to no JITs in any browser. I don't think I'd waste any time dealing with Wasm in a first-pass port (and, depending on adoption rates of Wasm, ever), when core browsing is suffering so badly.

Other than some papercut gfx bugs (#1339008 and #986328), Firefox runs correctly on PowerPC BE, both 32-bit and 64-bit. It's just dog slow because of a lack of JIT.

Thanks for the pointer towards what I'd need to look for here. I guess if you aren't going to focus there, I can get a head start next week.

[classilla]

By all means. I'm happy to advise if the changesets need explanation. You may need to go back into the old changeset packs to get the original diffs (IonMonkey became a thing in the 38.x timeframe).

One thing you probably also want to do is change it to properly use the link register rather than storing return addresses on top of the stack. This hurt alignment and fouled the LR cache but was the only way to solve certain problems at that time. Now you could just stick it in the generated prologue like any other compiled PPC function, which would be a definite speed improvement.

[darkbasic]

Hi, is there any news on the LE Power9 JIT?