Summary: | [DOMJIT] Support slow path call | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Yusuke Suzuki <ysuzuki> | ||||
Component: | JavaScriptCore | Assignee: | Yusuke Suzuki <ysuzuki> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | fpizlo, saam, sam | ||||
Priority: | P2 | ||||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | 162941 | ||||||
Bug Blocks: | 162544, 163005 | ||||||
Attachments: |
|
Description
Yusuke Suzuki
2016-10-05 10:39:00 PDT
If we expose variadic template-ed slow path generator that calls DFG / FTL slow path generators, it exposes almost all the DFG and FTL. For example, I tested the above design. And I ends up with exposing DFGSpeculativeJIT! That's bad. Instead, I'll take callOperation like design. We list up necessary calls in DFGSlowPathCall.h. And it will invoke DFG / FTL's appropriate functionality in DFGSlowPathCall.cpp. Created attachment 290802 [details]
Patch
Comment on attachment 290802 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290802&action=review > Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h:32 > +#define DOMJIT_SLOW_PATH_CALLS(macro) \ > + macro(J_JITOperation_EP, JSValueRegs, GPRReg) \ I wonder if it ever makes sense to expose a call API that's more abstract like this: class Call { struct Argument { Argument(GPRReg); Argument(JSValueRegs); Argument(immediate type: int32/int64/pointer); } Type m_resultType; Vector<Arguments> m_arguments; FunctionPtr m_function; }; and then have a function like: setupCallWithExecState(const Call& call); > Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp:41 > + params.addLatePath([=] (CCallHelpers& jit) { I wonder if it ever makes sense to have a normal call API. Comment on attachment 290802 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290802&action=review >> Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp:41 >> + params.addLatePath([=] (CCallHelpers& jit) { > > I wonder if it ever makes sense to have a normal call API. Oops, thanks. It's OK. fixed. Comment on attachment 290802 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290802&action=review >> Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h:32 >> + macro(J_JITOperation_EP, JSValueRegs, GPRReg) \ > > I wonder if it ever makes sense to expose a call API that's more abstract like this: > > class Call { > struct Argument { > Argument(GPRReg); > Argument(JSValueRegs); > Argument(immediate type: int32/int64/pointer); > } > Type m_resultType; > Vector<Arguments> m_arguments; > FunctionPtr m_function; > }; > and then have a function like: > setupCallWithExecState(const Call& call); Looks clean. I filed it in https://bugs.webkit.org/show_bug.cgi?id=163099 Comment on attachment 290802 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=290802&action=review >>> Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp:41 >>> + params.addLatePath([=] (CCallHelpers& jit) { >> >> I wonder if it ever makes sense to have a normal call API. > > Oops, thanks. It's OK. fixed. But, after considering, the above one is still useful. We can emit slow path after the fast path sequence by using addLatePath. Committed r206899: <http://trac.webkit.org/changeset/206899> |