[Webkit-unassigned] [Bug 150279] Explore adding a bare-bones backend to the FTL

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=150279

--- Comment #1 from Filip Pizlo <fpizlo at apple.com> ---
Current status:

- It runs a lot of JS code, but not all of it.  It usually runs it a bit slower than if it was compiled with LLVM.  The largest single benchmark slowdown is ~25% on mandreel, and the largest single benchmark speed-up is ~15% on imaging-gaussian-blur.  More than half of the benchmarks are neutral, but the slowdowns currently dominate.  We think we know all of the optimizations that we are missing, and most of them are trivial (like missing instruction selection patterns and missing strength reduction rules).

- Still need to finish gluing our FTL exception implementation to B3's notion of patchpoints.  Currently any code that uses exceptions in FTL B3 will crash or do strange things, because most of the exception paths are unimplemented.

- Still need to finish fixing the tailcall implementation.  It works for simple cases, but encounters an assertion in the callframe shuffler.  I haven't investigated this yet.

- ARM64 is being worked on, but it's not done, yet.

- We anticipate having to implement some more sophisticated optimizations in B3, like load elimination, tail duplication, CSE with Phi insertion, sinking, and probably LSR.  We don't think that we will need all of them, but probably some of them, to meet our performance goals.

- We anticipate having to beef up how the register allocator handles pressure.  Currently it does the classic kind of spilling where every access to a spilled temporary turns into a stack access.  That's suboptimal.  My current thinking is that we want something like what GCC calls "reload", but much more focused on spill handling and rematerialization.  Rematerialization is a big deal because the way JSC works, we end up with a lot of large constants, and they are easier to remat than spill.

We'll approach this by first filling in all coverage and getting FTL B3 to pass all tests.  We're not there yet, but it will probably happen soon - maybe even this week.  Then, we'll optimize the heck out of it.  We can turn on FTL B3, and remove FTL LLVM, if and when our Octane, JetStream, and Kraken scores with FTL B3 are as good as with FTL LLVM.  It's still possible (but unlikely) that we won't get there, in which case we can explore other options, like slotting FTL B3 in as a middle tier.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160105/05dd8e25/attachment.html>