Ignore:
Timestamp:
Jun 22, 2012, 4:32:59 PM (13 years ago)
Author:
[email protected]
Message:

DFG tier-up should happen in prologues, not epilogues
https://bugs.webkit.org/show_bug.cgi?id=89752

Reviewed by Geoffrey Garen.

This change has two outcomes:

1) Slightly reduces the likelihood that a function will be optimized both
standalone and via inlining. Previously, if you had a call sequence like foo()
calls bar() exactly once, and nobody else calls bar(), then bar() would get
optimized first (because it returns first) and then foo() gets optimized. If foo()
can inline bar() then that means that bar() gets optimized twice. But now, if we
optimize in prologues, then foo() will be optimized first. If it inlines bar(),
that means that there will no longer be any calls to bar().

2) It lets us kill some code in JITStubs. Epilogue tier-up was very different from
loop tier-up, since epilogue tier-up should not attempt OSR. But prologue tier-up
requires OSR (albeit really easy OSR since it's the top of the compilation unit),
so it becomes just like loop tier-up. As a result, we now have one optimization
hook (cti_optimize) instead of two (cti_optimize_from_loop and
cti_optimize_from_ret).

As a consequence of not having an optimization check in epilogues, the OSR exit
code must now trigger reoptimization itself instead of just signaling the epilogue
check to fire.

This also adds the ability to count the number of DFG compilations, which was
useful for debugging this patch and might be useful for other things in the future.

  • bytecode/CodeBlock.cpp:

(JSC::CodeBlock::reoptimize):
(JSC):

  • bytecode/CodeBlock.h:

(CodeBlock):

  • dfg/DFGByteCodeParser.cpp:

(JSC::DFG::ByteCodeParser::parseCodeBlock):

  • dfg/DFGDriver.cpp:

(DFG):
(JSC::DFG::getNumCompilations):
(JSC::DFG::compile):

  • dfg/DFGDriver.h:

(DFG):

  • dfg/DFGOSRExitCompiler.cpp:

(JSC::DFG::OSRExitCompiler::handleExitCounts):

  • dfg/DFGOperations.cpp:
  • dfg/DFGOperations.h:
  • jit/JIT.cpp:

(JSC::JIT::emitOptimizationCheck):

  • jit/JIT.h:
  • jit/JITCall32_64.cpp:

(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_ret_object_or_this):

  • jit/JITOpcodes.cpp:

(JSC::JIT::emit_op_ret):
(JSC::JIT::emit_op_ret_object_or_this):
(JSC::JIT::emit_op_enter):

  • jit/JITOpcodes32_64.cpp:

(JSC::JIT::emit_op_enter):

  • jit/JITStubs.cpp:

(JSC::DEFINE_STUB_FUNCTION):

  • jit/JITStubs.h:
File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/JavaScriptCore/dfg/DFGOperations.cpp

    r120989 r121073  
    3333#include "HostCallReturnValue.h"
    3434#include "GetterSetter.h"
    35 #include <wtf/InlineASM.h>
    3635#include "Interpreter.h"
     36#include "JIT.h"
    3737#include "JITExceptions.h"
    3838#include "JSActivation.h"
     
    4141#include "NameInstance.h"
    4242#include "Operations.h"
     43#include <wtf/InlineASM.h>
    4344
    4445#if ENABLE(DFG_JIT)
     
    12511252}
    12521253#endif
     1254
     1255extern "C" void DFG_OPERATION triggerReoptimizationNow(CodeBlock* codeBlock)
     1256{
     1257#if ENABLE(JIT_VERBOSE_OSR)
     1258    dataLog("%p: Entered reoptimize\n", codeBlock);
     1259#endif
     1260    // We must be called with the baseline code block.
     1261    ASSERT(JITCode::isBaselineCode(codeBlock->getJITType()));
     1262
     1263    // If I am my own replacement, then reoptimization has already been triggered.
     1264    // This can happen in recursive functions.
     1265    if (codeBlock->replacement() == codeBlock)
     1266        return;
     1267
     1268    // Otherwise, the replacement must be optimized code. Use this as an opportunity
     1269    // to check our logic.
     1270    ASSERT(codeBlock->hasOptimizedReplacement());
     1271    ASSERT(codeBlock->replacement()->getJITType() == JITCode::DFGJIT);
     1272
     1273    codeBlock->reoptimize();
     1274}
    12531275
    12541276} // extern "C"
Note: See TracChangeset for help on using the changeset viewer.