Specifically ... JSC_useBBQJIT - allows the BBQ JIT to be used if true JSC_useOMGJIT - allows the OMG JIT to be used if true JSC_useWasmLLIntPrologueOSR - allows prologue OSR from Wasm LLInt if true JSC_useWasmLLIntLoopOSR - allows loop OSR from Wasm LLInt if true JSC_useWasmLLIntEpilogueOSR - allows epilogue OSR from Wasm LLInt if true JSC_wasmFunctionIndexRangeToCompile=N:M - wasm function index range to allow compilation on, e.g. 1:100
<rdar://problem/59411390>
Created attachment 390611 [details] proposed patch.
Comment on attachment 390611 [details] proposed patch. View in context: https://bugs.webkit.org/attachment.cgi?id=390611&action=review r=me with one comment. > Source/JavaScriptCore/wasm/WasmSlowPaths.cpp:98 > + if (!Options::wasmFunctionIndexRangeToCompile().isInRange(codeBlock->functionIndex())) This functionIndex is per-wasm-module thing. If we have two wasm modules, they can have the same function index for different functions. Currently, I think this is OK. But maybe, should we introduce dfgWhitelist like mechanism instead?
(In reply to Yusuke Suzuki from comment #3) > > Source/JavaScriptCore/wasm/WasmSlowPaths.cpp:98 > > + if (!Options::wasmFunctionIndexRangeToCompile().isInRange(codeBlock->functionIndex())) > > This functionIndex is per-wasm-module thing. If we have two wasm modules, > they can have the same function index for different functions. > Currently, I think this is OK. But maybe, should we introduce dfgWhitelist > like mechanism instead? Yes, I understood this to be the case. It will do for now. Thanks.
Thanks for the review. Landed in r256500: <http://trac.webkit.org/r256500>.
These should all have been wrapped in UNLIKELY