[Webkit-unassigned] [Bug 169815] New: WebAssembly: eliminate redundant ARM64 TLS load

[bugzilla-daemon at webkit.org]

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

            Bug ID: 169815
           Summary: WebAssembly: eliminate redundant ARM64 TLS load
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jfbastien at apple.com
                CC: fpizlo at apple.com, jfbastien at apple.com,
                    keith_miller at apple.com, mark.lam at apple.com,
                    msaboff at apple.com, sbarati at apple.com
        Depends on: 169611
            Blocks: 159775

This is a small optimization, I'm not sure it'll pay off much but it's neat.

As part of bug #169611 we're moving the WebAssembly context to a TLS slot. On x86 that's a single load / store off the segment register, but on ARM64 it uses mrs + mask + {load,store}. the `mrs TPIDRRO EL0` instruction, coupled with the mask and the address generation, simply return the location of our TLS slot (the offset is defined as WTF_WASM_CONTEXT_KEY in wtf/FastTls.h). That value is idempotent as long as we're executing in the same thread, and that's an invariant of WebAssembly: different instances are set in that context but the location is the same per thread.

Right now this mrs+mask+memory combo is generated by the ARM64 macro assembler. This is inefficient. We could instead teach the compiler about the idempotent part (i.e. "get TLS slot #x") and then split off the load / store from that slot. For x86 that could mean combining both operations after the fact or keeping the same model we have now. For ARM64 that would allow us to eliminate redundant mrs+mask if profitable, or dematerializing them under register pressure.

-- 
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/20170317/c380de86/attachment.html>