Changeset 191514 in webkit


Ignore:
Timestamp:
Oct 23, 2015, 3:45:34 PM (10 years ago)
Author:
matthew_hanson@apple.com
Message:

Rollout r191395. rdar://problem/22846455

Location:
branches/safari-601.1.46-branch
Files:
6 edited

Legend:

Unmodified
Added
Removed
  • branches/safari-601.1.46-branch/Source/JavaScriptCore/ChangeLog

    r191463 r191514  
     12015-10-21  Matthew Hanson  <matthew_hanson@apple.com>
     2
     3        Rollout r191395. rdar://problem/22846455
     4
     5    2015-10-21  Filip Pizlo  <fpizlo@apple.com>
     6
     7            Failures in PutStackSinkingPhase should be less severe
     8            https://bugs.webkit.org/show_bug.cgi?id=150400
     9
     10            Reviewed by Geoffrey Garen.
     11
     12            Make the PutStackSinkingPhase abort instead of asserting. To test that it's OK to not have
     13            PutStackSinkingPhase run, this adds a test mode where we run without PutStackSinkingPhase.
     14
     15            * dfg/DFGPlan.cpp: Make it possible to not run PutStackSinkingPhase for tests.
     16            (JSC::DFG::Plan::compileInThreadImpl):
     17            * dfg/DFGPutStackSinkingPhase.cpp: PutStackSinkingPhase should abort instead of asserting, except when validation is enabled.
     18            * runtime/Options.h: Add an option for disabling PutStackSinkingPhase.
     19
    1202015-10-21  Matthew Hanson  <matthew_hanson@apple.com>
    221
  • branches/safari-601.1.46-branch/Source/JavaScriptCore/dfg/DFGPlan.cpp

    r191463 r191514  
    355355        // Ideally, these would be run to fixpoint with the object allocation sinking phase.
    356356        performArgumentsElimination(dfg);
    357         if (Options::usePutStackSinking())
    358             performPutStackSinking(dfg);
     357        performPutStackSinking(dfg);
    359358       
    360359        performConstantHoisting(dfg);
  • branches/safari-601.1.46-branch/Source/JavaScriptCore/dfg/DFGPutStackSinkingPhase.cpp

    r191463 r191514  
    231231                   
    232232                    if (node->op() == GetStack) {
    233                         // Handle the case that the input doesn't match our requirements. This is
    234                         // really a bug, but it's a benign one if we simply don't run this phase.
    235                         // It usually arises because of patterns like:
    236                         //
    237                         // if (thing)
    238                         //     PutStack()
    239                         // ...
    240                         // if (thing)
    241                         //     GetStack()
    242                         //
    243                         // Or:
    244                         //
    245                         // if (never happens)
    246                         //     GetStack()
    247                         //
    248                         // Because this phase runs early in SSA, it should be sensible to enforce
    249                         // that no such code pattern has arisen yet. So, when validation is
    250                         // enabled, we assert that we aren't seeing this. But with validation
    251                         // disabled we silently let this fly and we just abort this phase.
    252                         // FIXME: Get rid of all remaining cases of conflicting GetStacks.
    253                         // https://bugs.webkit.org/show_bug.cgi?id=150398
    254 
    255                         bool isConflicting =
    256                             deferred.operand(node->stackAccessData()->local) == ConflictingFlush;
    257                        
    258                         if (validationEnabled())
    259                             DFG_ASSERT(m_graph, node, !isConflicting);
    260 
    261                         if (isConflicting) {
    262                             // Oh noes! Abort!!
    263                             return false;
    264                         }
    265 
    266233                        // A GetStack doesn't affect anything, since we know which local we are reading
    267234                        // from.
  • branches/safari-601.1.46-branch/Source/JavaScriptCore/runtime/Options.h

    r191463 r191514  
    191191    v(bool, enableMovHintRemoval, true, nullptr) \
    192192    v(bool, enableObjectAllocationSinking, true, nullptr) \
    193     v(bool, usePutStackSinking, true, nullptr) \
    194193    \
    195194    v(bool, enableConcurrentJIT, true, "allows the DFG / FTL compilation in threads other than the executing JS thread") \
  • branches/safari-601.1.46-branch/Tools/ChangeLog

    r191495 r191514  
     12015-10-21  Matthew Hanson  <matthew_hanson@apple.com>
     2
     3        Rollout r191395. rdar://problem/22846455
     4
     5    2015-10-21  Filip Pizlo  <fpizlo@apple.com>
     6
     7            Failures in PutStackSinkingPhase should be less severe
     8            https://bugs.webkit.org/show_bug.cgi?id=150400
     9
     10            Reviewed by Geoffrey Garen.
     11
     12            Add a test mode for no PutStackSinkingPhase.
     13
     14            * Scripts/run-jsc-stress-tests:
     15
    1162015-10-23  Matthew Hanson  <matthew_hanson@apple.com>
    217
  • branches/safari-601.1.46-branch/Tools/Scripts/run-jsc-stress-tests

    r191463 r191514  
    711711end
    712712
    713 def runFTLNoCJITNoPutStackValidate
    714     run("ftl-no-cjit-no-put-stack-validate", "--validateGraph=true", "--usePutStackSinking=false", *(FTL_OPTIONS + NO_CJIT_OPTIONS)) if $enableFTL
    715 end
    716 
    717713def runFTLNoCJITNoInlineValidate
    718714    run("ftl-no-cjit-no-inline-validate", "--validateGraph=true", "--maximumInliningDepth=1", *(FTL_OPTIONS + NO_CJIT_OPTIONS)) if $enableFTL
     
    778774        runFTLNoCJITValidate
    779775        runFTLNoCJITNoInlineValidate
    780         runFTLNoCJITNoPutStackValidate
    781776        runFTLEager
    782777        runFTLEagerNoCJITValidate
Note: See TracChangeset for help on using the changeset viewer.