[Webkit-unassigned] [Bug 163171] New: B3 should efficiently emit great code for WebAssembly property accesses and bounds checks

[bugzilla-daemon at webkit.org]

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

            Bug ID: 163171
           Summary: B3 should efficiently emit great code for WebAssembly
                    property accesses and bounds checks
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fpizlo at apple.com

This implies a strategy where:

- The base and size of wasm memory are pinned to registers.
- B3 understands the meaning of a memory access or bounds check, so that existing optimizations can be used to remove them and new specialized optimizations can be added *easily*.
- Air understands the meaning of a pinned register, and for these registers, it understands *why* they are pinned.
- B3->Air lowering easily does all of the same fusion as now, and has new "fusions" for wasm memory accesses (basically, it will only fuze the offset and rely on lea for all else).
- B3->Air lowering should be able to select complex leas!  I think we forgot to implement that, but it will be super important now.
- Strength reduction knows about the whole guard page thingy.  It's gotta have some way of querying whether that's on or not, and how big that page is.  When it's non-zero, strength reduction has got to be able to do smart things with offset computations.
- The amount of IR used to represent a memory access should be minimal.

One way or another we'll need to write WebAssembly-specific compiler code that optimizes these accesses.  I think that code might as well live in B3, so B3 might as well know about WebAssembly.

I think we should do all of this with a Wasm flag and a WasmBoundsCheck opcode.

The most important is the Wasm flag, as in:

    Load<Wasm>(@ptr, offset = 0, guardedBytes = 0)

This zero-extends @ptr, adds it to the base register, then adds the given offset, and performs the access on the resulting pointer.  The Wasm flag may be applied to any memory access operation.  The guardedBytes tells you how many bytes of guard page are available.  You can safely increase the offset by up to that amount.  The offset and guardedBytes must be balanced: if you add to offset, you subtract from guardedBytes.  You are not allowed to reduce offset.

So, you can turn this:

Load<Wasm>(Add(@ptr, 666), offset = 0, guardedBytes = 4096)

into this:

Load<Wasm>(@ptr, offset = 666, guardedBytes = 3430)

And to perform bounds checks:

WasmBoundsCheck(@ptr, guardedBytes = 0)

The guardedBytes tells you how many bytes of guard page are available.  This means that you can turn this:

WasmBoundsCheck(Add(@ptr, 666), guardedBytes = 4096)

into this:

WasmBoundsCheck(@ptr, guardedBytes = 3430)

The reason for adding such Wasm-specific things is twofold: (1) it reduces the IR for an access and (2) it allows B3 to perform the guard page optimization for fusing an offset computing Add into a memory access.  I don't think B3 would have been able to do that optimization without deep knowledge of WebAssembly, and I don't think that we should invent a whole new compiler just to do Wasm optimizations - especially since the B3 IR is such a good fit for Wasm already.

Awkwardly, we need a way of tracking the fact that any call may cause a heap resize, which could change both base and size.  I think that the best way to achieve this is to simultaneously add a first-class pinned register support.  This means that Effects will have a RegisterSet.  Actually two: one for reads and one for writes.  Wow that'll be fun.

-- 
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/20161009/ff6a459b/attachment-0001.html>