Skip to content

W
webkit
Switch branch/tag
  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
  3. 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
  5. 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
  7. 20 Dec, 2013 3 commits
  9. 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
  11. 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
  13. 17 Dec, 2013 1 commit
  15. 16 Dec, 2013 2 commits
  17. 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
  19. 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
  21. 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
  23. 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
  25. 29 Nov, 2013 2 commits
  27. 28 Nov, 2013 2 commits
  29. 21 Nov, 2013 3 commits
  31. 20 Nov, 2013 2 commits
  33. 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
  35. 18 Nov, 2013 4 commits
  37. 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
  39. 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
  41. 12 Nov, 2013 1 commit
  43. 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
  45. 08 Nov, 2013 3 commits