• fpizlo@apple.com's avatar
    Get rid of the AlreadyInJSStack recoveries since they are totally redundant... · c6bb4a9f
    fpizlo@apple.com authored
    Get rid of the AlreadyInJSStack recoveries since they are totally redundant with the DisplacedInJSStack recoveries
    Reviewed by Mark Hahnenberg.
    This mostly just kills a bunch of code.
    But incidentaly while killing that code, I uncovered a bug in our FTL OSR entrypoint
    creation phase. The phase inserts a sequence of SetLocal(ExtractOSREntryLocal) nodes.
    If we hoist some type check into the local, then we might inject a conversion node
    between the ExtractOSREntryLocal and the SetLocal - for example we might put in a
    Int32ToDouble node. But currently the FixupPhase will make all conversion nodes placed
    on an edge of a SetLocal use forward exit. This then confuses the OSR exit machinery.
    When OSR exit sees a forward exit, it tries to "roll forward" execution from the exiting
    node to the first node that has a different CodeOrigin. This only works if the nodes
    after the forward exit are MovHints or other tnings that the OSR exit compiler can
    forward-execute. But here, it will see a bunch of SetLocal and ExtractOSREntryLocal
    nodes for the same bytecode index. Two possible solutions exist. We could teach the
    forward-execution logic how to deal with multiple SetLocals and ExtractOSREntryLocals.
    This would be a lot of complexity; right now it just needs to deal with exactly one
    SetLocal-like operation. The alternative is to make sure that the conversion node that
    we inject ends up exiting *backward* rather than forward.
    But making the conversion nodes exit backward is somewhat tricky. Before this patch,
    conversion nodes always exit forward for SetLocals and backwards otherwise. It turns out
    that the solution is to rationalize how we choose the speculation direciton for a
    conversion node. The conversion node's speculation direction should be the same as the
    speculation direction of the node for which it is doing a conversion. Since SetLocal's
    already exit forward by default, this policy preserves our previous behavior. But it
    also allows the OSR entrypoint creation phase to make its SetLocals exit backward
    Of course, if the SetLocal(ExtractOSREntryLocal) sequences exit backward, then we need
    to make sure that the OSR exit machine knows that the local variables are indeed live.
    Consider that if we have:
        a: ExtractOSREntryLocal(loc1)
        b: SetLocal(@a, loc1)
        c: ExtractOSRentryLocal(loc2)
        d: SetLocal(@c, loc2)
    Without additional magic, the exit at @b will think that loc2 is dead and the OSR exit
    compiler will clobber loc2 with Undefined. So we need to make sure that we actually
    emit code like:
        a: ExtractOSREntryLocal(loc1)
        b: ExtractOSREntryLocal(loc2)
        c: SetLocal(@a, loc1)
        d: SetLocal(@b, loc2)
        e: SetLocal(@a, loc1)
        f: SetLocal(@b, loc2)
    * CMakeLists.txt:
    * GNUmakefile.list.am:
    * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
    * JavaScriptCore.xcodeproj/project.pbxproj:
    * Target.pri:
    * bytecode/CodeOrigin.h:
    * bytecode/ValueRecovery.cpp: Added.
    * bytecode/ValueRecovery.h:
    * dfg/DFGFixupPhase.cpp:
    * dfg/DFGJITCode.cpp:
    * dfg/DFGNode.h:
    * dfg/DFGOSREntrypointCreationPhase.cpp:
    * dfg/DFGOSRExitCompiler32_64.cpp:
    * dfg/DFGOSRExitCompiler64.cpp:
    * dfg/DFGSpeculativeJIT.cpp:
    * dfg/DFGSpeculativeJIT.h:
    * dfg/DFGValueSource.h:
    * dfg/DFGVariableEventStream.cpp:
    * ftl/FTLLowerDFGToLLVM.cpp:
    * interpreter/Register.h:
    * runtime/Arguments.cpp:
    * runtime/Arguments.h:
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156677 268f45cc-cd09-0410-ab3c-d52691b4dbfc