1. 10 Jan, 2014 1 commit
    • benjamin@webkit.org's avatar
      Remove the BlackBerry port from trunk · 33b85d5b
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=126715
      
      Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-01-10
      Reviewed by Anders Carlsson.
      
      .: 
      
      * CMakeLists.txt:
      * Source/cmake/OptionsCommon.cmake:
      
      Source/JavaScriptCore: 
      
      * assembler/ARMAssembler.h:
      (JSC::ARMAssembler::cacheFlush):
      * assembler/ARMv7Assembler.h:
      (JSC::ARMv7Assembler::replaceWithJump):
      (JSC::ARMv7Assembler::maxJumpReplacementSize):
      (JSC::ARMv7Assembler::cacheFlush):
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):
      * heap/MachineStackMarker.cpp:
      (JSC::getPlatformThreadRegisters):
      (JSC::otherThreadStackPointer):
      (JSC::freePlatformThreadRegisters):
      * jit/ExecutableAllocator.h:
      
      Source/WebCore: 
      
      * html/canvas/WebGLRenderingContext.cpp:
      (WebCore::WebGLRenderingContext::readPixels):
      * platform/graphics/ImageBuffer.cpp:
      * platform/graphics/ImageBufferData.h:
      * platform/graphics/IntPoint.h:
      * platform/graphics/IntRect.h:
      * platform/graphics/IntSize.h:
      * platform/graphics/MediaPlayer.cpp:
      * platform/graphics/NativeImagePtr.h:
      * platform/graphics/OpenGLESShims.h:
      * platform/graphics/Path.cpp:
      (WebCore::Path::addPathForRoundedRect):
      * platform/graphics/Path.h:
      * platform/graphics/PlatformLayer.h:
      * platform/graphics/filters/CustomFilterValidatedProgram.cpp:
      * platform/graphics/filters/CustomFilterValidatedProgram.h:
      * platform/graphics/filters/FilterOperation.h:
      * platform/graphics/gpu/DrawingBuffer.cpp:
      * platform/graphics/opengl/Extensions3DOpenGLCommon.cpp:
      * platform/graphics/opengl/Extensions3DOpenGLES.cpp:
      (WebCore::Extensions3DOpenGLES::getGraphicsResetStatusARB):
      * platform/graphics/opengl/Extensions3DOpenGLES.h:
      * platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp:
      (WebCore::GraphicsContext3D::paintRenderingResultsToCanvas):
      (WebCore::GraphicsContext3D::prepareTexture):
      (WebCore::GraphicsContext3D::bindFramebuffer):
      (WebCore::GraphicsContext3D::compileShader):
      (WebCore::GraphicsContext3D::copyTexImage2D):
      (WebCore::GraphicsContext3D::copyTexSubImage2D):
      * platform/graphics/opengl/GraphicsContext3DOpenGLES.cpp:
      (WebCore::GraphicsContext3D::readPixels):
      (WebCore::GraphicsContext3D::readPixelsAndConvertToBGRAIfNecessary):
      (WebCore::GraphicsContext3D::reshapeFBOs):
      * platform/network/NetworkStateNotifier.h:
      * platform/network/ResourceHandle.h:
      * platform/network/ResourceHandleInternal.h:
      * platform/network/ResourceRequestBase.cpp:
      
      Tools: 
      
      * DumpRenderTree/DumpRenderTree.h:
      * DumpRenderTree/PixelDumpSupport.cpp:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@161699 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      33b85d5b
  2. 23 Dec, 2013 1 commit
    • benjamin@webkit.org's avatar
      Add class matching to the Selector Code Generator · 3a722540
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=126176
      
      Source/JavaScriptCore: 
      
      Reviewed by Antti Koivisto and Oliver Hunt.
      
      Add test and branch based on BaseIndex addressing for x86_64.
      Fast loops are needed to compete with clang on tight loops.
      
      * assembler/MacroAssembler.h:
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::branch64):
      (JSC::MacroAssemblerX86_64::branchPtr):
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::cmpq_rm):
      
      Source/WebCore: 
      
      Reviewed by Antti Koivisto.
      
      Add selector matching based on classname to the Selector Compiler.
      
      * cssjit/SelectorCompiler.cpp:
      (WebCore::SelectorCompiler::SelectorCodeGenerator::SelectorCodeGenerator):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementDataMatching):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementHasClasses):
      * dom/ElementData.h:
      (WebCore::ElementData::classNamesMemoryOffset):
      * dom/SpaceSplitString.h:
      (WebCore::SpaceSplitStringData::sizeMemoryOffset):
      (WebCore::SpaceSplitStringData::tokensMemoryOffset):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@161031 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3a722540
  3. 22 Dec, 2013 1 commit
    • benjamin@webkit.org's avatar
      Create a skeleton for CSS Selector code generation · 182c19a4
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=126044
      
      Source/JavaScriptCore: 
      
      Reviewed by Antti Koivisto and Gavin Barraclough.
      
      * assembler/LinkBuffer.h:
      Add a new owner UID for code compiled for CSS.
      Export the symbols needed to link code from WebCore.
      
      Source/WebCore: 
      
      Patch by Benjamin Poulain <bpoulain@apple.com> on 2013-12-22
      Reviewed by Antti Koivisto and Gavin Barraclough.
      
      Add CSSCompiler, which provides the basic infrastructure to compile
      CSS Selectors on x86_64.
      
      Compilation happens in two phases.
      1) The various matching and relation of each CSSSelector is aggregated into units
         matching a single element: SelectorFragment.
         SelectorFragment also knows about the relations between different fragments,
         and contains all the information to generate the code for a particular element.
      2) The compiler then goes over the fragments, and generate code based on the information
         of each fragment.
      
      It the current state, SelectorCompiler only compiles the tag matching selectors and
      any of the relation between selectors.
      
      Depending on the relation and position of a fragment, failure on traversal or matching
      does not necessarily causes the complete selector. A failure can cause matching to
      resume from the parent or the sibling of a previously visisted node.
      The implementation of this is done through the BacktrackingAction. In case of failure,
      the next starting state is setup and the program counter jumps back to the appropriate
      starting point.
      
      When backtracking, the method used to save the starting point depends on the type
      of backtracking.
      The child/parent relation (">") is very common so it uses an additional register to keep
      the next starting point (m_descendantBacktrackingStart).
      The indirect sibling relation ("~") is much less common and uses the stack to save
      the next starting point.
      
      * WebCore.xcodeproj/project.pbxproj:
      * cssjit/SelectorCompiler.cpp: Added.
      (WebCore::SelectorCompiler::SelectorFragment::SelectorFragment):
      (WebCore::SelectorCompiler::compileSelector):
      (WebCore::SelectorCompiler::fragmentRelationForSelectorRelation):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::SelectorCodeGenerator):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::compile):
      (WebCore::SelectorCompiler::updateChainStates):
      (WebCore::SelectorCompiler::isFirstAncestor):
      (WebCore::SelectorCompiler::isFirstAdjacent):
      (WebCore::SelectorCompiler::isAfterChildRelation):
      (WebCore::SelectorCompiler::solveBacktrackingAction):
      (WebCore::SelectorCompiler::requiresAdjacentTail):
      (WebCore::SelectorCompiler::requiresDescendantTail):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::computeBacktrackingInformation):
      (WebCore::SelectorCompiler::testIsElementFlagOnNode):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateWalkToParentElement):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateParentElementTreeWalker):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateAncestorTreeWalker):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateWalkToPreviousAdjacent):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateDirectAdjacentTreeWalker):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateIndirectAdjacentTreeWalker):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::markParentElementIfResolvingStyle):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::linkFailures):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateAdjacentBacktrackingTail):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateDescendantBacktrackingTail):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateBacktrackingTailsIfNeeded):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementMatching):
      (WebCore::SelectorCompiler::SelectorCodeGenerator::generateElementHasTagName):
      * cssjit/SelectorCompiler.h: Added.
      (WebCore::SelectorCompilationStatus::SelectorCompilationStatus):
      (WebCore::SelectorCompilationStatus::operator Status):
      (WebCore::SelectorCompiler::simpleSelectorCheckerFunction):
      (WebCore::SelectorCompiler::selectorCheckerFunctionWithCheckingContext):
      * dom/Element.cpp:
      (WebCore::Element::setChildrenAffectedByDirectAdjacentRules):
      (WebCore::Element::setChildrenAffectedByForwardPositionalRules):
      * dom/Element.h:
      (WebCore::Element::tagQNameMemoryOffset):
      (WebCore::Element::setChildrenAffectedByForwardPositionalRules):
      * dom/Node.h:
      (WebCore::Node::parentNodeMemoryOffset):
      (WebCore::Node::previousSiblingMemoryOffset):
      (WebCore::Node::nodeFlagsMemoryOffset):
      (WebCore::Node::flagIsElement):
      * dom/QualifiedName.h:
      (WebCore::QualifiedName::QualifiedNameImpl::localNameMemoryOffset):
      (WebCore::QualifiedName::QualifiedNameImpl::namespaceMemoryOffset):
      (WebCore::QualifiedName::implMemoryOffset):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160983 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      182c19a4
  4. 20 Dec, 2013 3 commits
  5. 19 Dec, 2013 1 commit
    • benjamin@webkit.org's avatar
      Add an utility class to simplify generating function calls · 05413aee
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=125972
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      Split branchTest32 in two functions: test32AndSetFlags and branchOnFlags.
      This is done to allow code where the flags are set, multiple operation that
      do not modify the flags occur, then the flags are used.
      
      This is used for function calls to test the return value while discarding the
      return register.
      
      * assembler/MacroAssemblerX86Common.h:
      (JSC::MacroAssemblerX86Common::test32AndSetFlags):
      (JSC::MacroAssemblerX86Common::branchOnFlags):
      (JSC::MacroAssemblerX86Common::branchTest32):
      
      Source/WebCore: 
      
      FunctionCall is a little helper class to make function calls from the JIT
      in 3 or 4 lines.
      
      FunctionCall takes a StackAllocator, a RegisterAllocator and a function pointer.
      When the call is generated, the helper saves the registers as necessary, aligns
      the stack, does the call, restores the stack, and restore the registers.
      
      * cssjit/FunctionCall.h: Added.
      (WebCore::FunctionCall::FunctionCall):
      (WebCore::FunctionCall::setFunctionAddress):
      (WebCore::FunctionCall::setFirstArgument):
      (WebCore::FunctionCall::call):
      
      (WebCore::FunctionCall::callAndBranchOnCondition): Most test functions used
      with FunctionCall return a boolean. When the boolean is the sole purpose of the function
      call, this provides an easy way to branch on the boolean without worrying about registers.
      
      The return register is tested first, then all the saved registers are restored from the stack
      (which can include the return register), finally the flags are used for a jump.
      
      (WebCore::FunctionCall::prepareAndCall):
      (WebCore::FunctionCall::cleanupPostCall):
      (WebCore::FunctionCall::saveAllocatedRegisters):
      (WebCore::FunctionCall::restoreAllocatedRegisters):
      * WebCore.xcodeproj/project.pbxproj:
      * cssjit/FunctionCall.h: Added.
      (WebCore::FunctionCall::FunctionCall):
      (WebCore::FunctionCall::setFunctionAddress):
      (WebCore::FunctionCall::setFirstArgument):
      (WebCore::FunctionCall::call):
      (WebCore::FunctionCall::callAndBranchOnCondition):
      (WebCore::FunctionCall::prepareAndCall):
      (WebCore::FunctionCall::cleanupPostCall):
      (WebCore::FunctionCall::saveAllocatedRegisters):
      (WebCore::FunctionCall::restoreAllocatedRegisters):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160881 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      05413aee
  6. 18 Dec, 2013 1 commit
    • benjamin@webkit.org's avatar
      Add a simple stack abstraction for x86_64 · da98b823
      benjamin@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=125908
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::addPtrNoFlags):
      Add an explicit abstraction for the "lea" instruction. This is needed
      by the experimental JIT to have add and substract without changing the flags.
      
      This is useful for function calls to test the return value, restore the registers,
      then branch on the flags from the return value.
      
      Source/WebCore: 
      
      StackAllocator provides an abstraction to make it hard to make mistakes and protects from obvious
      issues at runtime.
      
      The key roles of StackAllocators are:
      -Provide the necessary stack alignment for function calls (only x86_64 stack for now).
      -Provide ways to save registers on the stack, restore or discard them as needed.
      -Crash at runtime if an operation would obviously cause a stack inconsistency.
      
      The way simple inconsistencies are detected is through the StackReference object
      returned whenever something is added on the stack.
      The object keeps a reference to the offset of what has been pushed. When the StackReference
      is used to recover the register, if the offset is different, there is a missmatch between
      push() and pop() after the object was pushed.
      
      * cssjit/StackAllocator.h: Added.
      (WebCore::StackAllocator::StackReference::StackReference):
      (WebCore::StackAllocator::StackReference::operator unsigned):
      (WebCore::StackAllocator::StackAllocator):
      (WebCore::StackAllocator::~StackAllocator):
      (WebCore::StackAllocator::push):
      (WebCore::StackAllocator::pop):
      
      (WebCore::StackAllocator::alignStackPreFunctionCall):
      (WebCore::StackAllocator::unalignStackPostFunctionCall):
      Those helpers provide a simple way to have a valid stack prior to a function call.
      Since StackAllocator knows the offset and the platform rules, it can adjust the stack
      if needed for x86_64.
      
      (WebCore::StackAllocator::discard): Discard a single register or the full stack.
      
      (WebCore::StackAllocator::combine): combining stacks is the way to solve branches
      where the stack is used differently in each case.
      To do that, the stack is first copied to A and B. Each branch works on its own
      StackAllocator copy, then the two copies are linked together to the original stack.
      
      The copies ensure the local consistency in each branch, linking the copies ensure global
      consistencies and that both branches end in the same stack state.
      
      (WebCore::StackAllocator::offsetToStackReference): Helper function to access the stack by address
      through its StackReference.
      
      (WebCore::StackAllocator::reset):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160800 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      da98b823
  7. 17 Dec, 2013 1 commit
  8. 16 Dec, 2013 2 commits
  9. 10 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      Get rid of forward exit on DoubleAsInt32 · 5120492e
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125552
      
      PerformanceTests/SunSpider: 
      
      Reviewed by Oliver Hunt.
              
      Use SunSpider as a kind of spot-check for the
      no-architecture-specific-optimization paths in the compiler.
      
      * no-architecture-specific-optimizations.yaml: Added.
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      The forward exit was just there so that we wouldn't have to keep the inputs alive up to
      the DoubleAsInt32. That's dumb. Forward exits are a complicated piece of machinery and
      we shouldn't have it just for a bit of liveness micro-optimization.
              
      Also add a bunch of machinery to test this case on X86.
      
      * assembler/AbstractMacroAssembler.h:
      (JSC::optimizeForARMv7s):
      (JSC::optimizeForARM64):
      (JSC::optimizeForX86):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNodeType.h:
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
      * runtime/Options.h:
      * tests/stress/double-as-int32.js: Added.
      (foo):
      (test):
      
      Tools: 
      
      Reviewed by Oliver Hunt.
              
      Add some support for testing the generic (non-X86) paths on X86 by disabling
      architecture-specific optimizations (ASO's).
      
      * Scripts/run-javascriptcore-tests:
      * Scripts/run-jsc-stress-tests:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160411 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      5120492e
  10. 05 Dec, 2013 1 commit
    • fpizlo@apple.com's avatar
      FTL should use cvttsd2si directly for double-to-int32 conversions · 9ba2f35c
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125275
      
      Source/JavaScriptCore: 
      
      Reviewed by Michael Saboff.
              
      Wow. This was an ordeal. Using cvttsd2si was actually easy, but I learned, and
      sometimes even fixed, some interesting things:
              
      - The llvm.x86.sse2.cvttsd2si intrinsic can actually result in LLVM emitting a
        vcvttsd2si. I guess the intrinsic doesn't actually imply the instruction.
              
      - That whole thing about branchTruncateDoubleToUint32? Yeah we don't need that. It's
        better to use branchTruncateDoubleToInt32 instead. It has the right semantics for
        all of its callers (err, its one-and-only caller), and it's more likely to take
        fast path. This patch kills branchTruncateDoubleToUint32.
              
      - "a[i] = v; v = a[i]". Does this change v? OK, assume that 'a[i]' is a pure-ish
        operation - like an array access with 'i' being an integer index and we're not
        having a bad time. Now does this change v? CSE assumes that it doesn't. That's
        wrong. If 'a' is a typed array - the most sensible and pure kind of array - then
        this can be a truncating cast. For example 'v' could be a double and 'a' could be
        an integer array.
              
      - "v1 = a[i]; v2 = a[i]". Is v1 === v2 assuming that 'a[i]' is pure-ish? The answer
        is no. You could have a different arrayMode in each access. I know this sounds
        weird, but with concurrent JIT that might happen.
              
      This patch adds tests for all of this stuff, except for the first issue (it's weird
      but probably doesn't matter) and the last issue (it's too much of a freakshow).
      
      * assembler/MacroAssemblerARM64.h:
      * assembler/MacroAssemblerARMv7.h:
      * assembler/MacroAssemblerX86Common.h:
      * dfg/DFGCSEPhase.cpp:
      (JSC::DFG::CSEPhase::getByValLoadElimination):
      (JSC::DFG::CSEPhase::performNodeCSE):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::vectorType):
      (JSC::FTL::getUndef):
      (JSC::FTL::buildInsertElement):
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::doubleToInt32):
      (JSC::FTL::LowerDFGToLLVM::doubleToUInt32):
      (JSC::FTL::LowerDFGToLLVM::sensibleDoubleToInt32):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::insertElement):
      (JSC::FTL::Output::hasSensibleDoubleToInt):
      (JSC::FTL::Output::sensibleDoubleToInt):
      
      LayoutTests: 
      
      Reviewed by Michael Saboff.
      
      * js/regress/double-to-int32-typed-array-expected.txt: Added.
      * js/regress/double-to-int32-typed-array-no-inline-expected.txt: Added.
      * js/regress/double-to-int32-typed-array-no-inline.html: Added.
      * js/regress/double-to-int32-typed-array.html: Added.
      * js/regress/double-to-uint32-typed-array-expected.txt: Added.
      * js/regress/double-to-uint32-typed-array-no-inline-expected.txt: Added.
      * js/regress/double-to-uint32-typed-array-no-inline.html: Added.
      * js/regress/double-to-uint32-typed-array.html: Added.
      * js/regress/script-tests/double-to-int32-typed-array-no-inline.js: Added.
      (foo):
      (test):
      * js/regress/script-tests/double-to-int32-typed-array.js: Added.
      (foo):
      (test):
      * js/regress/script-tests/double-to-uint32-typed-array-no-inline.js: Added.
      (foo):
      (test):
      * js/regress/script-tests/double-to-uint32-typed-array.js: Added.
      (foo):
      (test):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160205 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      9ba2f35c
  11. 03 Dec, 2013 1 commit
    • msaboff@apple.com's avatar
      ARM64: Crash in JIT code due to improper reuse of cached memory temp register · 7e11b5f2
      msaboff@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=125181
      
      Reviewed by Geoffrey Garen.
      
      Changed load8() and load() to invalidate the memory temp CachedTempRegister when the
      destination of an absolute load is the memory temp register since the source address
      is also the memory temp register.  Change branch{8,32,64} of an AbsoluteAddress with
      a register to use the dataTempRegister as the destinate of the absolute load to
      reduce the chance that we need to invalidate the memory temp register cache.
      In the process, found and fixed an outright bug in branch8() where we'd load into
      the data temp register and then compare and branch on the memory temp register.
      
      * assembler/MacroAssemblerARM64.h:
      (JSC::MacroAssemblerARM64::load8):
      (JSC::MacroAssemblerARM64::branch32):
      (JSC::MacroAssemblerARM64::branch64):
      (JSC::MacroAssemblerARM64::branch8):
      (JSC::MacroAssemblerARM64::load):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@160056 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7e11b5f2
  12. 02 Dec, 2013 1 commit
    • mark.lam@apple.com's avatar
      Build failure when disabling JIT, YARR_JIT, and ASSEMBLER. · 10190c45
      mark.lam@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=123809.
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore: 
      
      Also fixed build when disabling the DISASSEMBLER.
      Added some needed #if's and some comments.
      
      * assembler/LinkBuffer.cpp:
      (JSC::LinkBuffer::finalizeCodeWithDisassembly):
      * dfg/DFGDisassembler.cpp:
      * dfg/DFGDisassembler.h:
      (JSC::DFG::Disassembler::Disassembler):
      (JSC::DFG::Disassembler::setStartOfCode):
      (JSC::DFG::Disassembler::setForBlockIndex):
      (JSC::DFG::Disassembler::setForNode):
      (JSC::DFG::Disassembler::setEndOfMainPath):
      (JSC::DFG::Disassembler::setEndOfCode):
      (JSC::DFG::Disassembler::dump):
      (JSC::DFG::Disassembler::reportToProfiler):
      * disassembler/Disassembler.cpp:
      * disassembler/X86Disassembler.cpp:
      * jit/FPRInfo.h:
      * jit/GPRInfo.h:
      * jit/JITDisassembler.cpp:
      * jit/JITDisassembler.h:
      (JSC::JITDisassembler::JITDisassembler):
      (JSC::JITDisassembler::setStartOfCode):
      (JSC::JITDisassembler::setForBytecodeMainPath):
      (JSC::JITDisassembler::setForBytecodeSlowPath):
      (JSC::JITDisassembler::setEndOfSlowPath):
      (JSC::JITDisassembler::setEndOfCode):
      (JSC::JITDisassembler::dump):
      (JSC::JITDisassembler::reportToProfiler):
      
      Source/WTF: 
      
      * wtf/Platform.h:
      - Ensure that the ASSEMBLER is enabled when the DISASSEMBLER is enabled.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159987 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      10190c45
  13. 29 Nov, 2013 2 commits
  14. 28 Nov, 2013 2 commits
  15. 21 Nov, 2013 3 commits
  16. 20 Nov, 2013 2 commits
  17. 19 Nov, 2013 3 commits
    • fpizlo@apple.com's avatar
      Infer constant global variables · 33961712
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124464
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      All global variables that are candidates for watchpoint-based constant inference (i.e.
      not 'const' variables) will now have WatchpointSet's associated with them and those
      are used to drive the inference by tracking three states of each variable:
              
      Uninitialized: the variable's value is Undefined and the WatchpointSet state is
          ClearWatchpoint.
              
      Initialized: the variable's value was set to something (could even be explicitly set
          to Undefined) and the WatchpointSet state is IsWatching.
              
      Invalidated: the variable's value was set to something else (could even be the same
          thing as before but the point is that a put operation did execute again) and the
          WatchpointSet is IsInvalidated.
              
      If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is
      IsWatching, then the current value of the variable can be folded in place of the get,
      and a watchpoint on the variable can be registered.
              
      We handle race conditions between the mutator and compiler by mandating that:
              
      - The mutator changes the WatchpointSet state after executing the put.
              
      - There is no opportunity to install code or call functions between when the mutator
        executes a put and changes the WatchpointSet state.
              
      - The compiler checks the WatchpointSet state prior to reading the value.
              
      The concrete algorithm used by the mutator is:
              
          1. Store the new value into the variable.
          --- Execute a store-store fence.
          2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes
             IsInvalidated); the IsWatching->IsInvalidated transition may end up firing
             watchpoints.
              
      The concrete algorithm that the compiler uses is:
              
          1. Load the state. If it's *not* IsWatching, then give up on constant inference.
          --- Execute a load-load fence.
          2. Load the value of the variable and use that for folding, while also registering
             a DesiredWatchpoint. The various parts of this step can be done in any order.
              
      The desired watchpoint registration will fail if the watchpoint set is already
      invalidated. Now consider the following interesting interleavings:
              
      Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store
          operation, and the variable is folded. The fencing ensures that C2 sees the value
          stored in M1 - i.e. we fold on the value that will actually be watchpointed. If
          before the compilation is installed the mutator executes another store then we
          will be sure that it will be a complete sequence of M1+M2 since compilations get
          installed at safepoints and never "in the middle" of a put_to_scope. Hence that
          compilation installation will be invalidated. If the M1+M2 sequence happens after
          the code is installed, then the code will be invalidated by triggering a jettison.
              
      Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is
          a sensible outcome since if the compiler read the variable's value, it would have
          seen Undefined.
              
      Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold.
      Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold.
      Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold.
      Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold.
              
      IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold.
              
      IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired
          watchpoint, and that watchpoint will get invalidated before the code is installed.
              
      IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated.
      IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated.
      IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated.
      IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated.
              
      Note that this kind of reasoning shows why having the mutator first bump the state and
      then store the new value would be wrong. If we had done that (M1 = bump state, M2 =
      execute put) then we could have the following deadly interleavings:
              
      Uninitialized->M1->C1->C2->M2:
      Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the
          compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the
          watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a
          value other than Undefined, and you're toast.
              
      You could fix this sort of thing by making the Desired Watchpoints machinery more
      sophisticated, for example having it track the value that was folded; if the global
      variable's value was later found to be different then we could invalidate the
      compilation. You could also fix it by having the compiler also check that the value of
      the variable is not Undefined before folding. While those all sound great, I decided
      to instead just use the right interleaving since that results in less code and feels
      more intuitive.
              
      This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic.
      It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is
      because 3d-cube takes global variable assignment slow paths very often. Note that this
      3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is
      also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue
      (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due
      to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the
      slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS
      programming often leads to global-var-based idioms and those variables tend to be
      assigned once, leading to excellent constant folding opportunities in an optimizing
      JIT. This is very evident in the speed-ups on JSRegress.
      
      * assembler/ARM64Assembler.h:
      (JSC::ARM64Assembler::dmbSY):
      * assembler/ARMv7Assembler.h:
      (JSC::ARMv7Assembler::dmbSY):
      * assembler/MacroAssemblerARM64.h:
      (JSC::MacroAssemblerARM64::memfence):
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::load8):
      (JSC::MacroAssemblerARMv7::memfence):
      * assembler/MacroAssemblerX86.h:
      (JSC::MacroAssemblerX86::load8):
      (JSC::MacroAssemblerX86::store8):
      * assembler/MacroAssemblerX86Common.h:
      (JSC::MacroAssemblerX86Common::getUnusedRegister):
      (JSC::MacroAssemblerX86Common::store8):
      (JSC::MacroAssemblerX86Common::memoryFence):
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::load8):
      (JSC::MacroAssemblerX86_64::store8):
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::movb_rm):
      (JSC::X86Assembler::movzbl_mr):
      (JSC::X86Assembler::mfence):
      (JSC::X86Assembler::X86InstructionFormatter::threeByteOp):
      (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/Watchpoint.cpp:
      (JSC::WatchpointSet::WatchpointSet):
      (JSC::WatchpointSet::add):
      (JSC::WatchpointSet::notifyWriteSlow):
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::state):
      (JSC::WatchpointSet::isStillValid):
      (JSC::WatchpointSet::addressOfSetIsNotEmpty):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::getJSConstantForValue):
      (JSC::DFG::ByteCodeParser::getJSConstant):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::isStronglyProvedConstantIn):
      (JSC::DFG::Node::hasIdentifierNumberForCheck):
      (JSC::DFG::Node::hasRegisterPointer):
      * dfg/DFGNodeFlags.h:
      * dfg/DFGNodeType.h:
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileNotifyPutGlobalVar):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * ftl/FTLAbbreviatedTypes.h:
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::buildFence):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileNotifyPutGlobalVar):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::fence):
      * jit/JIT.h:
      * jit/JITOperations.h:
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * llvm/LLVMAPIFunctions.h:
      * offlineasm/arm.rb:
      * offlineasm/arm64.rb:
      * offlineasm/cloop.rb:
      * offlineasm/instructions.rb:
      * offlineasm/x86.rb:
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::addGlobalVar):
      (JSC::JSGlobalObject::addFunction):
      * runtime/JSGlobalObject.h:
      (JSC::JSGlobalObject::addVar):
      (JSC::JSGlobalObject::addConst):
      * runtime/JSScope.cpp:
      (JSC::abstractAccess):
      * runtime/JSSymbolTableObject.h:
      (JSC::symbolTablePut):
      (JSC::symbolTablePutWithAttributes):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTableEntry::couldBeWatched):
      (JSC::SymbolTableEntry::prepareToWatch):
      (JSC::SymbolTableEntry::notifyWriteSlow):
      * runtime/SymbolTable.h:
      
      LayoutTests: 
      
      Reviewed by Sam Weinig.
      
      * js/regress/global-var-const-infer-expected.txt: Added.
      * js/regress/global-var-const-infer-fire-from-opt-expected.txt: Added.
      * js/regress/global-var-const-infer-fire-from-opt.html: Added.
      * js/regress/global-var-const-infer.html: Added.
      * js/regress/script-tests/global-var-const-infer-fire-from-opt.js: Added.
      (foo):
      (setA):
      (setB):
      (check):
      * js/regress/script-tests/global-var-const-infer.js: Added.
      (foo):
      (check):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159545 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      33961712
    • msaboff@apple.com's avatar
      REGRESSION(158384) ARMv7 point checks too restrictive for native calls to traditional ARM code · 3420f2cd
      msaboff@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124612
      
      Reviewed by Geoffrey Garen.
      
      Removed ASSERT checks (i.e. lower bit set) for ARM Thumb2 destination addresses related to
      calls since we are calling native ARM traditional functions like sin() and cos().
      
      * assembler/ARMv7Assembler.h:
      (JSC::ARMv7Assembler::linkCall):
      (JSC::ARMv7Assembler::relinkCall):
      * assembler/MacroAssemblerCodeRef.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159532 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3420f2cd
    • msaboff@apple.com's avatar
      REGRESSION (r159395): Error compiling for ARMv7 · c975139c
      msaboff@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124552
      
      Reviewed by Geoffrey Garen.
      
      Fixed the implementation of branch8(RelationalCondition cond, AbsoluteAddress address, TrustedImm32 right)
      to materialize and use address similar to other ARMv7 branchXX() functions.
      
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::branch8):
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159521 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      c975139c
  18. 18 Nov, 2013 4 commits
  19. 17 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      Simplify WatchpointSet state tracking · 09a6af08
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124465
      
      Reviewed by Sam Weinig.
              
      We previously represented the state of watchpoint sets using two booleans. But that
      makes it awkward to case over the state.
              
      We also previously supported a watchpoint set being both watched and invalidated. We
      never used that capability, and its presence was just purely confusing.
              
      This turns the whole thing into an enum.
      
      * assembler/MacroAssemblerARM64.h:
      (JSC::MacroAssemblerARM64::branch8):
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::branch8):
      * assembler/MacroAssemblerX86.h:
      (JSC::MacroAssemblerX86::branch8):
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::branch8):
      * bytecode/Watchpoint.cpp:
      (JSC::WatchpointSet::WatchpointSet):
      (JSC::WatchpointSet::add):
      (JSC::WatchpointSet::notifyWriteSlow):
      (JSC::InlineWatchpointSet::inflateSlow):
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::state):
      (JSC::WatchpointSet::isStillValid):
      (JSC::WatchpointSet::startWatching):
      (JSC::WatchpointSet::notifyWrite):
      (JSC::WatchpointSet::addressOfState):
      (JSC::InlineWatchpointSet::InlineWatchpointSet):
      (JSC::InlineWatchpointSet::hasBeenInvalidated):
      (JSC::InlineWatchpointSet::startWatching):
      (JSC::InlineWatchpointSet::notifyWrite):
      (JSC::InlineWatchpointSet::decodeState):
      (JSC::InlineWatchpointSet::encodeState):
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitVarInjectionCheck):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitVarInjectionCheck):
      * llint/LowLevelInterpreter.asm:
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * runtime/JSFunction.cpp:
      (JSC::JSFunction::JSFunction):
      * runtime/JSFunctionInlines.h:
      (JSC::JSFunction::JSFunction):
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::JSGlobalObject):
      * runtime/Structure.cpp:
      (JSC::Structure::Structure):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTableEntry::attemptToWatch):
      * runtime/SymbolTable.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159395 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      09a6af08
  20. 13 Nov, 2013 2 commits
    • aestes@apple.com's avatar
      Fix the ARM64 build after recent JavaScriptCore changes · 4f809911
      aestes@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124315
      
      Reviewed by Michael Saboff.
      
      Based on patches by myself, Filip Pizlo, Benjamin Poulain, and Michael Saboff.
      
      * Configurations/JavaScriptCore.xcconfig: Hid the symbol for
      std::bad_function_call.
      * JavaScriptCore.xcodeproj/project.pbxproj: Marked
      MacroAssemblerARM64.h and ARM64Assembler.h as Private headers.
      * assembler/ARM64Assembler.h:
      (JSC::ARM64Assembler::executableOffsetFor):
      * assembler/MacroAssemblerARM64.h: Removed ARM64's executableCopy(),
      which was removed from other assembler backends in r157690.
      (JSC::MacroAssemblerARM64::shouldBlindForSpecificArch): Added.
      (JSC::MacroAssemblerARM64::lshift64): Added.
      (JSC::MacroAssemblerARM64::mul64): Added.
      (JSC::MacroAssemblerARM64::rshift64): Added.
      (JSC::MacroAssemblerARM64::convertInt64ToDouble): Added.
      (JSC::MacroAssemblerARM64::branchMul64): Added.
      (JSC::MacroAssemblerARM64::branchNeg64): Added.
      (JSC::MacroAssemblerARM64::scratchRegisterForBlinding): Added.
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileArithDiv): Changed
      SpeculateIntegerOperand to SpeculateInt32Operand,
      nodeCanIgnoreNegativeZero() to bytecodeCanIgnoreNegativeZero(), and
      nodeUsedAsNumber() to bytecodeUsesAsNumber().
      (JSC::DFG::SpeculativeJIT::compileArithMod): Changed
      nodeCanIgnoreNegativeZero() to bytecodeCanIgnoreNegativeZero().
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159261 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      4f809911
    • commit-queue@webkit.org's avatar
      [sh4] Protect repatchCompact from flushConstantPool. · 92b506ca
      commit-queue@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=124278
      
      Patch by Julien Brianceau <jbriance@cisco.com> on 2013-11-13
      Reviewed by Michael Saboff.
      
      Random crashes may occur with sh4 architecture, when a flushConstantPool occurs in
      movlMemRegCompact. As in this case a branch opcode and the constant pool are put
      before the movlMemRegCompact, the branch itself is patched when calling repatchCompact
      instead of the mov instruction, which is really bad.
      
      * assembler/SH4Assembler.h:
      (JSC::SH4Assembler::repatchCompact): Handle this specific case and add an ASSERT.
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159203 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      92b506ca
  21. 12 Nov, 2013 1 commit
  22. 11 Nov, 2013 2 commits
    • rgabor@webkit.org's avatar
      Fix CPU(ARM_TRADITIONAL) build after r159039. · ebfd2507
      rgabor@webkit.org authored
      https://bugs.webkit.org/show_bug.cgi?id=124149
      
      Reviewed by Geoffrey Garen.
      
      * assembler/ARMAssembler.h:
      (JSC::ARMAssembler::firstRegister):
      (JSC::ARMAssembler::lastRegister):
      (JSC::ARMAssembler::firstFPRegister):
      (JSC::ARMAssembler::lastFPRegister):
      * assembler/MacroAssemblerARM.h:
      * jit/FPRInfo.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159055 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ebfd2507
    • fpizlo@apple.com's avatar
      Switch FTL GetById/PutById IC's over to using AnyRegCC · d2ceb399
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124094
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      This closes the loop on inline caches (IC's) in the FTL. The goal is to have IC's
      in LLVM-generated code that are just as efficient (if not more so) than what a
      custom JIT could do. As in zero sources of overhead. Not a single extra instruction
      or even register allocation pathology. We accomplish this by having two thingies in
      LLVM. First is the llvm.experimental.patchpoint intrinsic, which is sort of an
      inline machine code snippet that we can fill in with whatever we want and then
      modify subsequently. But you have only two choices of how to pass values to a
      patchpoint: (1) via the calling convention or (2) via the stackmap. Neither are good
      for operands to an IC (like the base pointer for a GetById, for example). (1) is bad
      because it results in things being pinned to certain registers a priori; a custom
      JIT (like the DFG) will not pin IC operands to any registers a priori but will allow
      the register allocator to do whatever it wants. (2) is bad because the operands may
      be spilled or may be represented in other crazy ways. You generally want an IC to
      have its operands in registers. Also, patchpoints only return values using the
      calling convention, which is unfortunate since it pins the return value to a
      register a priori. This is where the second thingy comes in: the AnyRegCC. This is
      a special calling convention only for use with patchpoints. It means that arguments
      passed "by CC" in the patchpoint can be placed in any register, and the register
      that gets used is reported as part of the stackmap. It also means that the return
      value (if there is one) can be placed in any register, and the stackmap will tell
      you which one it was. Thus, patchpoints combined with AnyRegCC mean that you not
      only get the kind of self-modifying code that you want for IC's, but you also get
      all of the register allocation goodness that a custom JIT would have given you.
      Except that you're getting it from LLVM and not a custom JIT. Awesome.
              
      Even though all of the fun stuff is on the LLVM side, this patch was harder than
      you'd expect.
              
      First the obvious bits:
              
      - IC patchpoints now use AnyRegCC instead of the C CC. (CC = calling convention.)
              
      - FTL::fixFunctionBasedOnStackMaps() now correctly figures out which registers the
        IC is supposed to use instead of assuming C CC argument registers.
              
      And then all of the stuff that broke and that this patch fixes:
              
      - IC sizing based on generating a dummy IC (what FTLInlineCacheSize did) is totally
        bad on x86-64, where various register permutations lead to bizarre header bytes
        and eclectic SIB encodings. I changed that to have magic constants, for now.
              
      - Slow path calls didn't preserve the CC return register.
              
      - Repatch's scratch register allocation would get totally confused if the operand
        registers weren't one of the DFG-style "temp" registers. And by "totally confused"
        I mean that it would crash.
              
      - We assumed that r10 is callee-saved. It's not. That one dude's PPT about x86-64
        cdecl that I found on the intertubes was not a trustworthy source of information,
        apparently.
              
      - Call repatching didn't know that the FTL does its IC slow calls via specially
        generated thunks. This was particularly fun to fix: basically, now when we relink
        an IC call in the FTL, we use the old call target to find the SlowPathCallKey,
        which tells us everything we need to know to generate (or look up) a new thunk for
        the new function we want to call.
              
      * assembler/MacroAssemblerCodeRef.h:
      (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
      (JSC::MacroAssemblerCodePtr::isEmptyValue):
      (JSC::MacroAssemblerCodePtr::isDeletedValue):
      (JSC::MacroAssemblerCodePtr::hash):
      (JSC::MacroAssemblerCodePtr::emptyValue):
      (JSC::MacroAssemblerCodePtr::deletedValue):
      (JSC::MacroAssemblerCodePtrHash::hash):
      (JSC::MacroAssemblerCodePtrHash::equal):
      * assembler/MacroAssemblerX86Common.h:
      * assembler/RepatchBuffer.h:
      (JSC::RepatchBuffer::RepatchBuffer):
      (JSC::RepatchBuffer::codeBlock):
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::setInstructionCallingConvention):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::fixFunctionBasedOnStackMaps):
      * ftl/FTLInlineCacheSize.cpp:
      (JSC::FTL::sizeOfGetById):
      (JSC::FTL::sizeOfPutById):
      * ftl/FTLJITFinalizer.cpp:
      (JSC::FTL::JITFinalizer::finalizeFunction):
      * ftl/FTLLocation.cpp:
      (JSC::FTL::Location::forStackmaps):
      * ftl/FTLLocation.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileGetById):
      (JSC::FTL::LowerDFGToLLVM::compilePutById):
      * ftl/FTLOSRExitCompiler.cpp:
      (JSC::FTL::compileStub):
      * ftl/FTLSlowPathCall.cpp:
      * ftl/FTLSlowPathCallKey.h:
      (JSC::FTL::SlowPathCallKey::withCallTarget):
      * ftl/FTLStackMaps.cpp:
      (JSC::FTL::StackMaps::Location::directGPR):
      (JSC::FTL::StackMaps::Location::restoreInto):
      * ftl/FTLStackMaps.h:
      * ftl/FTLThunks.h:
      (JSC::FTL::generateIfNecessary):
      (JSC::FTL::keyForThunk):
      (JSC::FTL::Thunks::keyForSlowPathCallThunk):
      * jit/FPRInfo.h:
      (JSC::FPRInfo::toIndex):
      * jit/GPRInfo.h:
      (JSC::GPRInfo::toIndex):
      (JSC::GPRInfo::debugName):
      * jit/RegisterSet.cpp:
      (JSC::RegisterSet::calleeSaveRegisters):
      * jit/RegisterSet.h:
      (JSC::RegisterSet::filter):
      * jit/Repatch.cpp:
      (JSC::readCallTarget):
      (JSC::repatchCall):
      (JSC::repatchByIdSelfAccess):
      (JSC::tryCacheGetByID):
      (JSC::tryCachePutByID):
      (JSC::tryBuildPutByIdList):
      (JSC::resetGetByID):
      (JSC::resetPutByID):
      * jit/ScratchRegisterAllocator.h:
      (JSC::ScratchRegisterAllocator::lock):
      
      Source/WTF: 
      
      Reviewed by Sam Weinig.
              
      I needed to add another set operation, namely filter(), which is an in-place set
      intersection.
      
      * wtf/BitVector.cpp:
      (WTF::BitVector::filterSlow):
      * wtf/BitVector.h:
      (WTF::BitVector::filter):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159039 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d2ceb399
  23. 08 Nov, 2013 3 commits