1. 11 Jan, 2013 11 commits
  2. 10 Jan, 2013 1 commit
    • zandobersek@gmail.com's avatar
      Remove the ENABLE_ANIMATION_API feature define occurences · 1594f89f
      zandobersek@gmail.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106544
      
      Reviewed by Simon Fraser.
      
      The Animation API code was removed in r137243. The ENABLE_ANIMATION_API
      feature define handling still lingers in various build systems and configurations
      but is of no use, so it should be removed.
      
      .:
      
      * Source/cmake/OptionsBlackBerry.cmake:
      * Source/cmake/OptionsEfl.cmake:
      * Source/cmake/WebKitFeatures.cmake:
      * Source/cmakeconfig.h.cmake:
      
      Source/JavaScriptCore:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WebCore:
      
      No new tests - no new functionality.
      
      * Configurations/FeatureDefines.xcconfig:
      * GNUmakefile.features.am.in:
      
      Source/WebKit/mac:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WebKit2:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Tools:
      
      * Scripts/webkitperl/FeatureList.pm:
      * qmake/mkspecs/features/features.pri:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139324 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1594f89f
  3. 09 Jan, 2013 7 commits
  4. 08 Jan, 2013 6 commits
    • oliver@apple.com's avatar
      Support op_typeof in the DFG · e722ad0f
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=98898
      
      Reviewed by Filip Pizlo.
      
      Adds a TypeOf node to the DFG to support op_typeof.
      
      To avoid adding too much GC horror, this also makes the
      common strings portion of the SmallString cache strongly
      referenced.
      
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::execute):
        We try to determine the result early here, and substitute in a constant.
        Otherwise we leave the node intact, and set the result type to SpecString.
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
        Parse op_typeof
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::performNodeCSE):
        TypeOf nodes can be subjected to pure CSE
      * dfg/DFGCapabilities.h:
      (JSC::DFG::canCompileOpcode):
        We can handle typeof.
      * dfg/DFGNodeType.h:
      (DFG):
        Define the node.
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
        Add operationTypeOf to support the non-trivial cases.
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
        Actual codegen
      * runtime/Operations.cpp:
      (JSC::jsTypeStringForValue):
      (JSC):
      * runtime/Operations.h:
      (JSC):
        Some refactoring to allow us to get the type string for an
        object without needing a callframe.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139145 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      e722ad0f
    • fpizlo@apple.com's avatar
      DFG shouldn't treat the 'this' argument as being captured if a code block uses arguments · 8757a202
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106398
      <rdar://problem/12439776>
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      This is a possible optimization for inlined calls, and fixes crashes for inlined constructors, in the case
      that the inlined code used arguments. The problem was that assuming that 'this' was captured implies the
      assumption that it was initialized by the caller, which is wrong for constructors and this.
              
      Also added a pretty essential DFG IR validation rule: we shouldn't have any live locals at the top of the
      root block. This helps to catch this bug: our assumption that 'this' was captured in an inlined constructor
      that used arguments led to liveness for the temporary that would have held 'this' in the caller being
      propagated all the way up to the entrypoint of the function.
      
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::isCaptured):
      * dfg/DFGValidate.cpp:
      (JSC::DFG::Validate::validate):
      (JSC::DFG::Validate::reportValidationContext):
      (Validate):
      (JSC::DFG::Validate::dumpGraphIfAppropriate):
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
      
      * fast/js/dfg-inline-constructor-that-uses-arguments-expected.txt: Added.
      * fast/js/dfg-inline-constructor-that-uses-arguments.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-inline-constructor-that-uses-arguments.js: Added.
      (Foo):
      (bar):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139136 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8757a202
    • fpizlo@apple.com's avatar
      REGRESSION (r138921): Crash in JSC::Arguments::create · 608ecbe4
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106329
      <rdar://problem/12974196>
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      Arguments::finishCreation() that takes an InlineCallFrame* needs to understand that the callee can
      be unset, indicating that the callee needs to be loaded from the true call frame. This adds a
      method to InlineCallFrame to do just that.
      
      * bytecode/CodeOrigin.cpp:
      (JSC::InlineCallFrame::calleeForCallFrame):
      * bytecode/CodeOrigin.h:
      (InlineCallFrame):
      * runtime/Arguments.h:
      (JSC::Arguments::finishCreation):
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
      
      * fast/js/dfg-create-inlined-arguments-in-closure-inline-expected.txt: Added.
      * fast/js/dfg-create-inlined-arguments-in-closure-inline.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-create-inlined-arguments-in-closure-inline.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139109 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      608ecbe4
    • fpizlo@apple.com's avatar
      DFG initrinsic handling should ensure that we backwards propagate the fact... · 8dafd7dd
      fpizlo@apple.com authored
      DFG initrinsic handling should ensure that we backwards propagate the fact that all operands may escape
      https://bugs.webkit.org/show_bug.cgi?id=106365
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      Use the fact that Phantom means that things escaped, and just insert Phantoms for all
      of the operands.
      
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleCall):
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
              
      Add tests that cover the possible badness that could occur for all of those
      intrinsics that don't intrinsically (pun sort of intended) cause escapeage
      to happen. As in, if we did happen to know for sure that what we want is
      ArithSqrt, then we would have a guarantee that ArithSqrt does not by itself
      use its operands in a way that involves NodeUsedAsOther. But when ArithSqrt
      is inserted because of intrinsic optimization (i.e. something like
      Math.sqrt(blah)) then the intrinsic machinery needs to indicate that blah
      could escape in the case that we didn't end up doing ArithSqrt because we
      exited prior to it and called some other function.
      
      * fast/js/dfg-abs-backwards-propagation-expected.txt: Added.
      * fast/js/dfg-abs-backwards-propagation.html: Added.
      * fast/js/dfg-max-backwards-propagation-expected.txt: Added.
      * fast/js/dfg-max-backwards-propagation.html: Added.
      * fast/js/dfg-min-backwards-propagation-expected.txt: Added.
      * fast/js/dfg-min-backwards-propagation.html: Added.
      * fast/js/dfg-proven-sqrt-backwards-propagation-expected.txt: Added.
      * fast/js/dfg-proven-sqrt-backwards-propagation.html: Added.
      * fast/js/dfg-sqrt-backwards-propagation-expected.txt: Added.
      * fast/js/dfg-sqrt-backwards-propagation.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-abs-backwards-propagation.js: Added.
      (foo):
      (bar):
      * fast/js/script-tests/dfg-max-backwards-propagation.js: Added.
      (foo):
      (bar):
      * fast/js/script-tests/dfg-min-backwards-propagation.js: Added.
      (foo):
      (bar):
      * fast/js/script-tests/dfg-proven-sqrt-backwards-propagation.js: Added.
      (foo):
      (bar):
      * fast/js/script-tests/dfg-sqrt-backwards-propagation.js: Added.
      (foo):
      (bar):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139098 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      8dafd7dd
    • fpizlo@apple.com's avatar
      If array allocation profiling causes a new_array to allocate double arrays,... · 0d5d62cb
      fpizlo@apple.com authored
      If array allocation profiling causes a new_array to allocate double arrays, then the holes should end up being correctly initialized
      https://bugs.webkit.org/show_bug.cgi?id=106363
      
      Reviewed by Mark Hahnenberg.
      
      Source/JavaScriptCore: 
      
      * runtime/JSArray.h:
      (JSC::JSArray::tryCreateUninitialized):
      
      LayoutTests: 
      
      * fast/js/jsc-test-list:
      * fast/js/new-array-double-with-holes-expected.txt: Added.
      * fast/js/new-array-double-with-holes.html: Added.
      * fast/js/script-tests/new-array-double-with-holes.js: Added.
      (foo):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139094 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0d5d62cb
    • fpizlo@apple.com's avatar
      DFG should backwards-propagate NodeUsedAsValue for Phantom · 2abd9749
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106299
      
      Reviewed by Mark Hahnenberg.
              
      This is currently benign because Phantom is only inserted by the bytecode parser for
      things that already happen to be used in contexts that backwards propagate
      NodeUsedAsValue. But that doesn't change the fact that the semantics of Phantom are
      that the value can be arbitrarily used by the baseline JIT.
      
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139068 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2abd9749
  5. 07 Jan, 2013 5 commits
    • fpizlo@apple.com's avatar
      Rationalize closure call heuristics and profiling · 806b5821
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106270
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      Did a number of things:
              
      - CallLinkInfo now remembers if it was ever a closure call, and CallLinkStatus uses
        this. Reduces the likelihood that we will inline a closure call as if it was a
        normal call.
              
      - Made InlineCallFrame print inferred function names, and refactored
        CodeBlock::inferredName() to better use FunctionExecutable's API.
              
      - Made bytecode dumping print frequent exit sites that led to recompilation.
              
      - Made bytecode dumping for op_call and op_construct print what the CallLinkStatus
        saw.
              
      * bytecode/CallLinkInfo.h:
      (JSC::CallLinkInfo::CallLinkInfo):
      (CallLinkInfo):
      * bytecode/CallLinkStatus.cpp:
      (JSC::CallLinkStatus::computeFor):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::inferredName):
      (JSC::CodeBlock::dumpBytecodeCommentAndNewLine):
      (JSC::CodeBlock::printCallOp):
      * bytecode/CodeOrigin.cpp:
      (JSC::CodeOrigin::dump):
      (JSC::InlineCallFrame::inferredName):
      (JSC):
      (JSC::InlineCallFrame::dumpBriefFunctionInformation):
      (JSC::InlineCallFrame::dump):
      * bytecode/CodeOrigin.h:
      (InlineCallFrame):
      * bytecode/DFGExitProfile.cpp:
      (JSC::DFG::ExitProfile::exitSitesFor):
      (DFG):
      * bytecode/DFGExitProfile.h:
      (ExitProfile):
      * jit/JITStubs.cpp:
      (JSC::DEFINE_STUB_FUNCTION):
      
      Source/WTF: 
      
      Reviewed by Oliver Hunt.
              
      Add a macro to add a method to a class that returns a dumper. Allows you to have
      secondary dump() methods for dumping either more or less information.
      
      * wtf/PrintStream.h:
      (WTF):
      
      Tools: 
      
      Reviewed by Oliver Hunt.
              
      Add ability to use display-profiler-output via a pipe, and add the ability to dump
      all generated code ('display *' or 'd *').
      
      * Scripts/display-profiler-output:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139021 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      806b5821
    • rniwa@webkit.org's avatar
      Source/JavaScriptCore: Sorted the xcodeproj file. · 657d387a
      rniwa@webkit.org authored
      * JavaScriptCore.xcodeproj/project.pbxproj:
      
      Tools: Sorted more xcodeproj files.
      
      * MiniBrowser/MiniBrowser.xcodeproj/project.pbxproj:
      * TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:
      * WebKitLauncher/WebKitLauncher.xcodeproj/project.pbxproj:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139012 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      657d387a
    • fpizlo@apple.com's avatar
      Unreviewed, it should be possible to build JSC on ARM. · 536df7cb
      fpizlo@apple.com authored
      Source/JavaScriptCore: 
      
      * API/JSBase.h:
      * jit/JITStubs.cpp:
      (JSC::performPlatformSpecificJITAssertions):
      (JSC):
      * jit/JITStubs.h:
      (JSC):
      * jit/JITThunks.cpp:
      (JSC::JITThunks::JITThunks):
      * jit/JITThunks.h:
      (JITThunks):
      * offlineasm/armv7.rb:
      * runtime/JSGlobalData.cpp:
      (JSC::JSGlobalData::JSGlobalData):
      
      Source/WTF: 
      
      * wtf/FastMalloc.cpp:
      (WTF::TCMalloc_PageHeap::IncrementalScavenge):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@139004 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      536df7cb
    • commit-queue@webkit.org's avatar
      MIPS LLInt implementation. · 99609ea7
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=99706
      
      Patch by Balazs Kilvady <kilvadyb@homejinni.com> on 2013-01-07
      Reviewed by Filip Pizlo.
      
      LLInt implementation for MIPS.
      
      Source/JavaScriptCore:
      
      * assembler/MacroAssemblerMIPS.h:
      (JSC::MacroAssemblerMIPS::jump):
      * dfg/DFGOperations.cpp:
      (JSC):
      * jit/JITStubs.cpp:
      (JSC):
      * jit/JITStubs.h:
      (JITStackFrame):
      * llint/LLIntOfflineAsmConfig.h:
      * llint/LowLevelInterpreter.asm:
      * llint/LowLevelInterpreter32_64.asm:
      * offlineasm/backends.rb:
      * offlineasm/instructions.rb:
      * offlineasm/mips.rb: Added.
      
      Source/WTF:
      
      * wtf/Platform.h:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138970 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      99609ea7
    • mhahnenberg@apple.com's avatar
      testapi is failing with a block-related error in the Objc API · d292112c
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106055
      
      Reviewed by Geoffrey Garen.
      
      Casting a block to a bool will always return true, which isn't the behavior that is intended here.
      Instead we need to call the block, but C semantics don't allow this, so we need to change
      testapi.m to be Objective-C++ and therefore testapi.mm.
      
      * API/tests/testapi.m: Removed.
      * API/tests/testapi.mm: Copied from Source/JavaScriptCore/API/tests/testapi.m.
      (blockSignatureContainsClass):
      * JavaScriptCore.xcodeproj/project.pbxproj:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138957 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d292112c
  6. 06 Jan, 2013 2 commits
    • fpizlo@apple.com's avatar
      Simplify slow case profiling · 1b694198
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106208
      
      Reviewed by Mark Rowe.
              
      Removing the minimum execution ratio portion of slow case profiling, which allows
      the removal of a field from CodeBlock. This appears to be performance neutral,
      implying that the complexity incurred by the previous heuristic was purely
      harmful: it made the code more complicated, and it made CodeBlock larger, without
      resulting in any measurable benefits.
      
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::likelyToTakeSlowCase):
      (JSC::CodeBlock::couldTakeSlowCase):
      (JSC::CodeBlock::likelyToTakeSpecialFastCase):
      (JSC::CodeBlock::couldTakeSpecialFastCase):
      (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
      (JSC::CodeBlock::likelyToTakeAnySlowCase):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompile):
      * runtime/Options.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138924 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      1b694198
    • fpizlo@apple.com's avatar
      DFG should inline closure calls · 5e2296a2
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106067
      
      Reviewed by Gavin Barraclough.
              
      This adds initial support for inlining closure calls to the DFG. A call is considered
      to be a closure call when the JSFunction* varies, but always has the same executable.
      We already have closure call inline caching in both JITs, which works by checking that
      the callee has an expected structure (as a cheap way of detecting that it is in fact
      a JSFunction) and an expected executable. Closure call inlining uses profiling data
      aggregated by CallLinkStatus to decide when to specialize the call to the particular
      structure/executable, and inline the call rather than emitting a call sequence. When
      we choose to do a closure inline rather than an ordinary inline, a number of things
      change about how inlining is performed:
              
      - The inline is guarded by a CheckStructure/CheckExecutable rather than a
        CheckFunction.
              
      - Instead of propagating a constant value for the scope, we emit GetMyScope every time
        that the scope is needed, which loads the scope from a local variable. We do similar
        things for the callee.
              
      - The prologue of the inlined code includes SetMyScope and SetCallee nodes to eagerly
        plant the scope and callee into the "true call frame", i.e. the place on the stack
        where the call frame would have been if the call had been actually performed. This
        allows GetMyScope/GetCallee to work as they would if the code wasn't inlined. It
        also allows for trivial handling of scope and callee for call frame reconstruction
        upon stack introspection and during OSR.
              
      - A new node called GetScope is introduced, which just gets the scope of a function.
        This node has the expected CSE support. This allows for the
        SetMyScope(GetScope(@function)) sequence to set up the scope in the true call frame.
              
      - GetMyScope/GetCallee CSE can match against SetMyScope/SetCallee, which means that
        the GetMyScope/GetCallee nodes emitted during parsing are often removed during CSE,
        if we can prove that it is safe to do so.
              
      - Inlining heuristics are adjusted to grok the cost of inlining a closure. We are
        less likely to inline a closure call than we are to inline a normal call, since we
        end up emitting more code for closures due to CheckStructure, CheckExecutable,
        GetScope, SetMyScope, and SetCallee.
              
      Additionally, I've fixed the VariableEventStream to ensure that we don't attempt to
      plant Undefined into the true call frames. This was previously a harmless oversight,
      but it becomes quite bad if OSR is relying on the scope/callee already having been
      set and not subsequently clobbered by the OSR itself.
              
      This is a ~60% speed-up on programs that frequently make calls to closures. It's
      neutral on V8v7 and other major benchmark suites.
              
      The lack of a definite speed-up is likely due the fact that closure inlining currently
      does not do any cardinality [1] optimizations. We don't observe when a closure was
      constructed within its caller, and so used the scope from its caller; and furthermore
      we have no facility to detect when the scope is single. All scoped variable accesses
      are assumed to be multiple instead. A subsequent step will be to ensure that closure
      call inlining will be single and loving it.
              
      [1] Single and loving it: Must-alias analysis for higher-order languages. Suresh
          Jagannathan, Peter Thiemann, Stephen Weeks, and Andrew Wright. In POPL '98.
      
      * bytecode/CallLinkStatus.cpp:
      (JSC::CallLinkStatus::dump):
      * bytecode/CallLinkStatus.h:
      (JSC::CallLinkStatus::isClosureCall):
      (CallLinkStatus):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::globalObjectFor):
      (JSC):
      * bytecode/CodeBlock.h:
      (CodeBlock):
      * bytecode/CodeOrigin.cpp:
      (JSC::InlineCallFrame::dump):
      * dfg/DFGAbstractState.cpp:
      (JSC::DFG::AbstractState::execute):
      * dfg/DFGByteCodeParser.cpp:
      (ByteCodeParser):
      (JSC::DFG::ByteCodeParser::handleCall):
      (JSC::DFG::ByteCodeParser::emitFunctionChecks):
      (JSC::DFG::ByteCodeParser::handleInlining):
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::pureCSE):
      (CSEPhase):
      (JSC::DFG::CSEPhase::getCalleeLoadElimination):
      (JSC::DFG::CSEPhase::checkExecutableElimination):
      (JSC::DFG::CSEPhase::getMyScopeLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::mightInlineFunctionForClosureCall):
      * dfg/DFGCapabilities.h:
      (DFG):
      (JSC::DFG::mightInlineFunctionForClosureCall):
      (JSC::DFG::canInlineFunctionForClosureCall):
      (JSC::DFG::canInlineFunctionFor):
      * dfg/DFGNode.h:
      (Node):
      (JSC::DFG::Node::hasExecutable):
      (JSC::DFG::Node::executable):
      * dfg/DFGNodeType.h:
      (DFG):
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGVariableEventStream.cpp:
      (JSC::DFG::VariableEventStream::reconstruct):
      * runtime/Options.h:
      (JSC):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138921 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5e2296a2
  7. 05 Jan, 2013 2 commits
    • fpizlo@apple.com's avatar
      Data flow paths that carry non-numbers, non-undefined, non-null values should... · 179645f2
      fpizlo@apple.com authored
      Data flow paths that carry non-numbers, non-undefined, non-null values should not cause subtractions and arithmetic additions (i.e. ++) to speculate double
      https://bugs.webkit.org/show_bug.cgi?id=106190
      
      Reviewed by Sam Weinig.
              
      The problem is that the DFG logic for deciding when to speculate integer was
      confusing the special case of ValueAdd (where non-numeric values should cause us
      to not speculate integer, because we want to fall off into the generic case) with
      the more normal case of ArithAdd and ArithSub (where we want to speculate integer
      unless we have evidence that the operands are doubles, since the DFG doesn't have
      generic handling of those operations). Prior to this change doing a - b where
      either a or b were possibly non-numeric would always force the subtraction to be
      done using doubles.
      
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::addSpeculationMode):
      (Graph):
      (JSC::DFG::Graph::valueAddSpeculationMode):
      (JSC::DFG::Graph::arithAddSpeculationMode):
      (JSC::DFG::Graph::addImmediateShouldSpeculateInteger):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138915 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      179645f2
    • fpizlo@apple.com's avatar
      DFG should trust array profiling over value profiling · c4e758bf
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106155
      
      Reviewed by Gavin Barraclough.
              
      The real problem is that prediction propagation is not flow-sensitive. We had code
      like:
              
      var a = (some load from memory); // returns either an array or false
      if (a)
          a[i] = v;
              
      Because 'a' could be 'false', we were emitting a fully generic unoptimized PutByVal.
      This patch changes ArrayMode to ignore the type of the base of an array access, if
      array profiling tells us that the array access can be optimized.
              
      In the future, we could probably make this work even better with some flow
      sensitivity in the prediction propagator, but I also tend to think that this is a
      more robust overall solution. If we ever did want to support array accesses on
      array-or-false then we should change the array profiler to be able to tell us that
      this is what is going on.
              
      3.7% speed-up on V8/earley.
      
      * dfg/DFGArrayMode.cpp:
      (JSC::DFG::ArrayMode::refine):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138890 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c4e758bf
  8. 04 Jan, 2013 3 commits
    • fpizlo@apple.com's avatar
      Rationalize exit site profiling for calls · a7536f9c
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106150
      
      Reviewed by Sam Weinig.
              
      This adds two new exit kinds for calls: BadFunction and BadExecutable. The latter is not used
      yet, but is already integrated with profiling. CheckFunction uses a BadFunction speculation
      instead of BadCache, now. This allows CallLinkStatus to turn itself into a closure call status
      if we had a BadFunction exit site but the CallLinkInfo told us to use a non-closure call. This
      might happen if we had call unlinking that led to information loss along the way.
              
      No performance impact. This is meant as another step towards inlining closure calls.
      
      * bytecode/CallLinkStatus.cpp:
      * bytecode/CallLinkStatus.h:
      (JSC::CallLinkStatus::setIsProved):
      (JSC::CallLinkStatus::setHasBadFunctionExitSite):
      (CallLinkStatus):
      (JSC::CallLinkStatus::setHasBadCacheExitSite):
      (JSC::CallLinkStatus::setHasBadExecutableExitSite):
      * bytecode/ExitKind.cpp:
      (JSC::exitKindToString):
      * bytecode/ExitKind.h:
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::handleCall):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138871 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a7536f9c
    • fpizlo@apple.com's avatar
      DFG should not elide CheckStructure if it's needed to perform a cell check · 0825c817
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=106074
      
      Source/JavaScriptCore: 
      
      Reviewed by Ryosuke Niwa.
              
      The problem here was that the constant folding phase was misinterpreting the meaning of the sets
      in DFG::AbstractValue.  AbstractValue describes a constraint on the values that a variable (i.e.
      a DFG Node, or a virtual register, i.e. local or argument) may have. It does so by containing
      four sets: the set of JSValues (either empty, the singleton set containing one JSValue, or the
      set of all JSValues); the set of "current known" structures, i.e. the set of structures that you
      already know that this value may have right now (also either empty, the singleton set, or the set
      of all structures); the set of "future possible" structures, i.e. the set of structures that this
      value could have in the future if none of the structure transition watchpoints for those
      structures had fired (also empty, singleton, or all); and the set of types, which is a
      SpeculatedType bitmask. The correct way to interpret the sets is to think of the AbstractValue as
      the intersection of these three sets of values:
              
      - The set of JSValues that have a type that belongs to the m_type set.
      - If m_value is not the empty value then: the set of all JSValues that are == m_value;
                                          else: the set of all JSValues.
        where '==' is as defined by JSValue::operator==.
      - Union of { the set of all cells that have a structure that belongs to m_currentKnownStructure }
             and { the set of all JSValues that are not cells }.
              
      You can then further intersect this set with the following set, if you guard the code with
      watchpoints on all structures in the m_futurePossibleStructure:
              
      - Union of { the set of all cells that have a structure that belongs to m_futurePossibleStructure }
             and { the set of all JSValues that are not cells }.
              
      One way to think of this is that m_currentKnownStructure is filtered by m_futurePossibleStructure
      (i.e. is set to the intersection of m_currentKnownStructure and m_futurePossibleStructure), if the
      code for which you're doing this is always preceded by watchpoints on all structures in
      m_futurePossibleStructure, and is always before any side-effects that could change the structures
      of objects.
              
      The incorrect optimization related to CheckStructure. CheckStructure checks that the value is a
      cell, and that it has a particular structure. It was incorrectly assuming that you could eliminate
      the CheckStructure, if m_currentKnownStructure contained the structure that CheckStructure was
      checking. But this is not the case, since m_currentKnownStructure does not prove that the value is
      a cell with a particular structure; it only proves that if the value was a cell then it would have
      a particular structure. Hence, to eliminate CheckStructure, it is also necessary to check that
      AbstractValue::m_type contains only cells (i.e. isCellSpeculation(m_type) == true).
              
      It wasn't doing that, and this changes makes sure that it does do that.
      
      * dfg/DFGConstantFoldingPhase.cpp:
      (JSC::DFG::ConstantFoldingPhase::foldConstants):
      
      LayoutTests: 
      
      Reviewed by Ryosuke Niwa.
      
      * fast/js/dfg-check-structure-elimination-for-non-cell-expected.txt: Added.
      * fast/js/dfg-check-structure-elimination-for-non-cell.html: Added.
      * fast/js/jsc-test-list:
      * fast/js/script-tests/dfg-check-structure-elimination-for-non-cell.js: Added.
      (foo):
      (bar):
      (baz):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138862 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0825c817
    • adamk@chromium.org's avatar
      Remove ENABLE_MUTATION_OBSERVERS #define · a0129590
      adamk@chromium.org authored
      https://bugs.webkit.org/show_bug.cgi?id=105459
      
      Reviewed by Ryosuke Niwa.
      
      .:
      
      * Source/cmake/WebKitFeatures.cmake:
      * Source/cmakeconfig.h.cmake:
      
      Source/JavaScriptCore:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WebCore:
      
      The flag has been on by default for quite awhile now (nearly a year)
      and the feature is a standardized part of DOM4.
      
      The only place it was disabled was under "unstable" features for the
      gtk port, but the fact that it's shipping in several major WebKit
      browsers as well as Firefox suggests that it's not too unstable.
      
      * Configurations/FeatureDefines.xcconfig:
      * GNUmakefile.am: Removed ENABLE_MUTATION_OBSERVERS from the "unstable features" list.
      * GNUmakefile.features.am.in:
      * bindings/js/JSDictionary.cpp:
      (WebCore):
      (WebCore::JSDictionary::convertValue):
      * bindings/js/JSDictionary.h:
      * bindings/js/JSMainThreadExecState.cpp:
      (WebCore::JSMainThreadExecState::didLeaveScriptContext):
      * bindings/js/JSMutationCallbackCustom.cpp:
      * bindings/js/JSMutationObserverCustom.cpp:
      * bindings/v8/V8GCController.cpp:
      * bindings/v8/V8RecursionScope.cpp:
      (WebCore::V8RecursionScope::didLeaveScriptContext):
      * bindings/v8/custom/V8MutationCallbackCustom.cpp:
      * bindings/v8/custom/V8MutationObserverCustom.cpp:
      * css/PropertySetCSSStyleDeclaration.cpp:
      (WebCore::PropertySetCSSStyleDeclaration::setCssText):
      (WebCore::PropertySetCSSStyleDeclaration::setProperty):
      (WebCore::PropertySetCSSStyleDeclaration::removeProperty):
      (WebCore::PropertySetCSSStyleDeclaration::setPropertyInternal):
      * dom/CharacterData.cpp:
      (WebCore::CharacterData::dispatchModifiedEvent):
      * dom/ChildListMutationScope.cpp:
      * dom/ChildListMutationScope.h:
      * dom/ContainerNode.cpp:
      (WebCore::ContainerNode::insertBefore):
      (WebCore::ContainerNode::replaceChild):
      (WebCore::willRemoveChild):
      (WebCore::willRemoveChildren):
      (WebCore::ContainerNode::appendChild):
      (WebCore::updateTreeAfterInsertion):
      * dom/Document.cpp:
      (WebCore::Document::Document):
      * dom/Document.h:
      (Document):
      * dom/Element.cpp:
      (WebCore::Element::willModifyAttribute):
      * dom/MutationCallback.h:
      * dom/MutationCallback.idl:
      * dom/MutationObserver.cpp:
      * dom/MutationObserver.h:
      * dom/MutationObserver.idl:
      * dom/MutationObserverInterestGroup.cpp:
      * dom/MutationObserverInterestGroup.h:
      * dom/MutationObserverRegistration.cpp:
      * dom/MutationObserverRegistration.h:
      * dom/MutationRecord.cpp:
      * dom/MutationRecord.h:
      * dom/MutationRecord.idl:
      * dom/Node.cpp:
      (WebCore::Node::clearRareData):
      (WebCore::Node::setTextContent):
      (WebCore::Node::didMoveToNewDocument):
      (WebCore::Node::notifyMutationObserversNodeWillDetach):
      * dom/Node.h:
      (Node):
      * dom/NodeRareData.cpp:
      (SameSizeAsNodeRareData):
      (WebCore::NodeRareData::reportMemoryUsage):
      * dom/NodeRareData.h:
      (NodeRareData):
      (WebCore::NodeRareData::ensureTransientMutationObserverRegistry):
      * editing/markup.cpp:
      (WebCore::replaceChildrenWithFragment):
      (WebCore::replaceChildrenWithText):
      * page/DOMWindow.idl:
      
      Source/WebKit/blackberry:
      
      * WebCoreSupport/AboutDataEnableFeatures.in:
      
      Source/WebKit/chromium:
      
      * features.gypi:
      * src/WebKit.cpp:
      (WebKit::initialize):
      (WebKit::shutdown):
      
      Source/WebKit/efl:
      
      * WebCoreSupport/DumpRenderTreeSupportEfl.cpp:
      (DumpRenderTreeSupportEfl::deliverAllMutationsIfNecessary):
      
      Source/WebKit/gtk:
      
      * WebCoreSupport/DumpRenderTreeSupportGtk.cpp:
      (DumpRenderTreeSupportGtk::deliverAllMutationsIfNecessary):
      
      Source/WebKit/mac:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WebKit2:
      
      * Configurations/FeatureDefines.xcconfig:
      
      Tools:
      
      * Scripts/webkitperl/FeatureList.pm:
      * qmake/mkspecs/features/features.pri:
      
      WebKitLibraries:
      
      * win/tools/vsprops/FeatureDefines.vsprops:
      * win/tools/vsprops/FeatureDefinesCairo.vsprops:
      
      LayoutTests:
      
      Remove references to ENABLE(MUTATION_OBSERVERS) from tests.
      
      * fast/dom/MutationObserver/cross-document.html:
      * fast/dom/MutationObserver/database-callback-delivery.html:
      * fast/dom/MutationObserver/disconnect-cancel-pending.html:
      * fast/dom/MutationObserver/filesystem-callback-delivery.html:
      * fast/dom/MutationObserver/mutation-observer-constructor.html:
      * fast/dom/MutationObserver/observe-attributes.html:
      * fast/dom/MutationObserver/observe-characterdata.html:
      * fast/dom/MutationObserver/observe-childList.html:
      * fast/dom/MutationObserver/observe-exceptions.html:
      * fast/dom/MutationObserver/observe-subtree.html:
      * fast/dom/MutationObserver/takeRecords.html:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@138811 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a0129590
  9. 03 Jan, 2013 3 commits