Changeset 164558 in webkit for trunk/Source/JavaScriptCore/dfg/DFGCapabilities.h

Timestamp:

Feb 23, 2014, 10:48:43 AM (11 years ago)

Author:

[email protected]

Message:

Refine DFG+FTL inlining and compilation limits
​https://bugs.webkit.org/show_bug.cgi?id=129212

Reviewed by Mark Hahnenberg.

Allow larger functions to be DFG-compiled. Institute a limit on FTL compilation,
and set that limit quite high. Institute a limit on inlining-into. The idea here is
that large functions tend to be autogenerated, and code generators like emscripten
appear to leave few inlining opportunities anyway. Also, we don't want the code
size explosion that we would risk if we allowed compilation of a large function and
then inlined a ton of stuff into it.

This is a 0.5% speed-up on Octane v2 and almost eliminates the typescript
regression. This is a 9% speed-up on AsmBench.

• bytecode/CodeBlock.cpp:

(JSC::CodeBlock::noticeIncomingCall):

• dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::handleInlining):

• dfg/DFGCapabilities.h:

(JSC::DFG::isSmallEnoughToInlineCodeInto):

• ftl/FTLCapabilities.cpp:

(JSC::FTL::canCompile):

• ftl/FTLState.h:

(JSC::FTL::shouldShowDisassembly):

• runtime/Options.h:

File:

• trunk/Source/JavaScriptCore/dfg/DFGCapabilities.h (modified) (1 diff)

trunk/Source/JavaScriptCore/dfg/DFGCapabilities.h

@@ -145 +145 @@
 }
 
+inline bool isSmallEnoughToInlineCodeInto(CodeBlock* codeBlock)
+{
+    return codeBlock->instructionCount() <= Options::maximumInliningCallerSize();
+}
+
 } } // namespace JSC::DFG