Bug 166486

Summary: WebAssembly -> JS: don't do a double entry
Product: WebKit Reporter: JF Bastien <jfbastien>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: jfbastien, keith_miller, sbarati
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 165282    
Bug Blocks: 161709    

Description JF Bastien 2016-12-26 16:51:05 PST
We have createJSToWasmWrapper as well as WebAssemblyFunction::call. We should merge the two, probably to B3 code or MacroAssembler code.
Comment 1 JF Bastien 2016-12-26 16:52:01 PST
Let's also figure out what vmEntryToWasm should be.
Comment 2 JF Bastien 2017-01-02 17:31:45 PST
We should also consider optimizing as discussed here:

> > > > Source/JavaScriptCore/wasm/js/WebAssemblyInstanceConstructor.cpp:90
> > > > +        // Always start with a dummy Memory, so that wasm -> wasm thunks avoid checking for a nullptr Memory when trying to set pinned registers.
> > > > +        Wasm::Memory memory;
> > > > +        instance->setMemory(vm, JSWebAssemblyMemory::create(vm, exec->lexicalGlobalObject()->WebAssemblyMemoryStructure(), WTFMove(memory)));
> > > 
> > > This makes me wonder if we're better off just having the callee instead of
> > > caller generate a wasm->wasm call thunk. Maybe we should do that in a later
> > > patch, or at least have a bug open to consider it.
> > 
> > Yeah I guess we could have an off-to-the-side entrypeint from "other wasm",
> > in addition to the regular "entry from this wasm instance", for all of the
> > exported functions. We'd need to also change the callee codegen, but then we
> > wouldn't need to tail (or rather, we'd inline that tail).
> > 
> > That could be more efficient.
> Yeah, let's open a bug and deal with it later.