Skip to content
  • fpizlo@apple.com's avatar
    DFG::ByteCodeParser should do surgical constant folding to reduce load on the optimization fixpoint · cb6fd793
    fpizlo@apple.com authored
    https://bugs.webkit.org/show_bug.cgi?id=109000
    
    Reviewed by Oliver Hunt.
            
    Previously our source parser's ASTBuilder did some surgical constant folding, but it
    didn't cover some cases.  It was particularly incapable of doing constant folding for
    cases where we do some minimal loop peeling in the bytecode generator - since it
    didn't "see" those constants prior to the peeling.  Example:
    
    for (var i = 0; i < 4; ++i)
        things;
    
    This will get peeled just a bit by the bytecode generator, so that the "i < 4" is
    duplicated both at the top of the loop and the bottom.  This means that we have a
    constant comparison: "0 < 4", which the bytecode generator emits without any further
    thought.
    
    The DFG optimization fixpoint of course folds this and simplifies the CFG 
    accordingly, but this incurs a compile-time cost.  The purpose of this change is to
    do some surgical constant folding in the DFG's bytecode parser, so that such
    constructs reduce load on the CFG simplifier and the optimization fixpoint.  The goal
    is not to cover all cases, since the DFG CFA and CFG simplifier have a powerful
    sparse conditional constant propagation that we can always fall back on. Instead the
    goal is to cover enough cases that for common small functions we don't have to
    perform such transformations, thereby reducing compile times.
            
    This also refactors m_inlineStackEntry->m_inlineCallFrame to be a handy method call
    and also adds the notion of a TriState-based JSValue::pureToBoolean(). Both of these
    things are used by the folder.
            
    As well, care has been taken to make sure that the bytecode parser only does folding
    that is statically provable, and that doesn't arise out of speculation. This means
    we cannot fold on data flow that crosses inlining boundaries. On the other hand, the
    folding that the bytecode parser uses doesn't require phantoming anything. Such is
    the trade-off: for anything that we do need phantoming, we defer it to the
    optimization fixpoint.
            
    Slight SunSpider speed-up.
    
    * dfg/DFGByteCodeParser.cpp:
    (JSC::DFG::ByteCodeParser::get):
    (JSC::DFG::ByteCodeParser::getLocal):
    (JSC::DFG::ByteCodeParser::setLocal):
    (JSC::DFG::ByteCodeParser::flushDirect):
    (JSC::DFG::ByteCodeParser::flushArgumentsAndCapturedVariables):
    (JSC::DFG::ByteCodeParser::toInt32):
    (ByteCodeParser):
    (JSC::DFG::ByteCodeParser::inlineCallFrame):
    (JSC::DFG::ByteCodeParser::currentCodeOrigin):
    (JSC::DFG::ByteCodeParser::canFold):
    (JSC::DFG::ByteCodeParser::handleInlining):
    (JSC::DFG::ByteCodeParser::getScope):
    (JSC::DFG::ByteCodeParser::parseResolveOperations):
    (JSC::DFG::ByteCodeParser::parseBlock):
    (JSC::DFG::ByteCodeParser::parseCodeBlock):
    * dfg/DFGNode.h:
    (JSC::DFG::Node::isStronglyProvedConstantIn):
    (Node):
    * runtime/JSCJSValue.h:
    * runtime/JSCJSValueInlines.h:
    (JSC::JSValue::pureToBoolean):
    (JSC):
    
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@142162 268f45cc-cd09-0410-ab3c-d52691b4dbfc
    cb6fd793