fourthTier: Rationalize Node::replacement
https://bugs.webkit.org/show_bug.cgi?id=118774

Reviewed by Oliver Hunt.

- Clearing of replacements is now done in Graph::clearReplacements().

- New nodes now have replacement set to 0.

- Node::replacement is now part of a 'misc' union. I'll be putting at least
  one other field into that union as part of LICM work (see
  https://bugs.webkit.org/show_bug.cgi?id=118749).

* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::run):
(JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
(JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::run):
(JSC::DFG::CSEPhase::setReplacement):
(JSC::DFG::CSEPhase::performBlockCSE):
* dfg/DFGGraph.cpp:
(DFG):
(JSC::DFG::Graph::clearReplacements):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::performSubstitutionForEdge):
(Graph):
* dfg/DFGNode.h:
(JSC::DFG::Node::Node):
* dfg/DFGSSAConversionPhase.cpp:
(JSC::DFG::SSAConversionPhase::run):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153278 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: Add a phase to create loop pre-headers
https://bugs.webkit.org/show_bug.cgi?id=118778

Reviewed by Oliver Hunt.

Add a loop pre-header creation phase. Any loop that doesn't already have
just one predecessor that isn't part of the loop has a pre-header
prepended. All non-loop predecessors then jump to that pre-header.

Also fix a handful of bugs:

- DFG::Analysis should set m_valid before running the analysis, since that
  makes it easier to use ASSERT(m_valid) in the analysis' methods, which
  may be called by the analysis before the analysis completes. NaturalLoops
  does this with loopsOf().

- NaturalLoops::headerOf() was missing a check for innerMostLoopOf()
  returning 0, since that'll happen if the block isn't in any loop.

- Change BlockInsertionSet to dethread the graph, since anyone using it
  will want to do so.

- Change dethreading to ignore SSA form graphs.

This also adds NaturalLoops::belongsTo(), which I always used in the
pre-header creation phase. I didn't end up using it but I'll probably use
it in the near future.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAnalysis.h:
(JSC::DFG::Analysis::computeIfNecessary):
* dfg/DFGBlockInsertionSet.cpp:
(JSC::DFG::BlockInsertionSet::execute):
* dfg/DFGCriticalEdgeBreakingPhase.cpp:
(JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dethread):
* dfg/DFGLoopPreHeaderCreationPhase.cpp: Added.
(DFG):
(LoopPreHeaderCreationPhase):
(JSC::DFG::LoopPreHeaderCreationPhase::LoopPreHeaderCreationPhase):
(JSC::DFG::LoopPreHeaderCreationPhase::run):
(JSC::DFG::performLoopPreHeaderCreation):
* dfg/DFGLoopPreHeaderCreationPhase.h: Added.
(DFG):
* dfg/DFGNaturalLoops.h:
(NaturalLoop):
(JSC::DFG::NaturalLoops::headerOf):
(JSC::DFG::NaturalLoops::innerMostLoopOf):
(JSC::DFG::NaturalLoops::innerMostOuterLoop):
(JSC::DFG::NaturalLoops::belongsTo):
(NaturalLoops):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):

Conflicts:
	Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153279 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: CFA should consider live-at-head for clobbering and dumping
https://bugs.webkit.org/show_bug.cgi?id=118857

Reviewed by Mark Hahnenberg.

- clobberStructures() was not considering nodes live-at-head when in SSA
  form. This means it would fail to clobber some structures.

- dump() was not considering nodes live-at-head when in SSA form. This
  means it wouldn't dump everything that you might be interested in.

- AbstractState::m_currentNode is a useless variable and we should get
  rid of it.

* dfg/DFGAbstractState.cpp:
(JSC::DFG::AbstractState::AbstractState):
(JSC::DFG::AbstractState::beginBasicBlock):
(JSC::DFG::AbstractState::reset):
(JSC::DFG::AbstractState::startExecuting):
(JSC::DFG::AbstractState::clobberStructures):
(JSC::DFG::AbstractState::dump):
* dfg/DFGAbstractState.h:
(AbstractState):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153280 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG shouldn't create CheckStructures for array accesses except if the ArrayMode implies an original array access
https://bugs.webkit.org/show_bug.cgi?id=118867

Reviewed by Mark Hahnenberg.

This allows us to kill off a bunch of code in the parser, in fixup, and to simplify
ArrayProfile.

It also makes it easier to ask any array-using node how to create its type check.

Doing this required fixing a bug in LowLevelInterpreter64, where it was storing into
an array profile, thinking that it was storing into a value profile. Reshuffling the
fields in ArrayProfile revealed this.

* bytecode/ArrayProfile.cpp:
(JSC::ArrayProfile::computeUpdatedPrediction):
(JSC::ArrayProfile::briefDescriptionWithoutUpdating):
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::ArrayProfile):
(ArrayProfile):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::updateAllArrayPredictions):
(JSC::CodeBlock::updateAllPredictions):
* bytecode/CodeBlock.h:
(CodeBlock):
(JSC::CodeBlock::updateAllArrayPredictions):
* dfg/DFGArrayMode.h:
(ArrayMode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(FixupPhase):
(JSC::DFG::FixupPhase::checkArray):
(JSC::DFG::FixupPhase::blessArrayOperation):
* llint/LowLevelInterpreter64.asm:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153281 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: Decouple the way that CFA stores its state from the way it does abstract interpretation
https://bugs.webkit.org/show_bug.cgi?id=118835

Reviewed by Oliver Hunt.

This separates AbstractState into two things:

- InPlaceAbstractState, which can tell you the abstract state of anything you
  might care about, and uses the old AbstractState's algorithms and data
  structures for doing so.

- AbstractInterpreter<AbstractStateType>, which can execute a DFG::Node* with
  respect to an AbstractStateType. Currently we always use
  AbstractStateType = InPlaceAbstractState. But we could drop in an other
  class that supports basic primitives like forNode() and variables().

This is important because:

- We want to hoist things out of loops.

- We don't know what things rely on what type checks.

- We only want to hoist type checks out of loops if they aren't clobbered.

- We may want to still hoist things that depended on those type checks, if it's
  safe to do those things based on the CFA state at the tail of the loop
  pre-header.

- We don't want things to rely on their type checks by way of a token, because
  that's just weird.

So, we want to be able to have a special form of the CFA that can
incrementally update a basic block's state-at-tail, and we want to be able to
do this for multiple blocks simultaneously. This requires *not* storing the
per-node state in the nodes themselves, but instead using the at-tail HashMap
directly.

Hence we need to have a way of making the abstract interpreter (i.e.
AbstractState::execute) polymorphic with respect to state representation. Put
another way, we need to separate the way that abstract state is represented
from the way DFG IR is abstractly interpreted.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreter.h: Added.
(DFG):
(AbstractInterpreter):
(JSC::DFG::AbstractInterpreter::forNode):
(JSC::DFG::AbstractInterpreter::variables):
(JSC::DFG::AbstractInterpreter::needsTypeCheck):
(JSC::DFG::AbstractInterpreter::filterEdgeByUse):
(JSC::DFG::AbstractInterpreter::filter):
(JSC::DFG::AbstractInterpreter::filterArrayModes):
(JSC::DFG::AbstractInterpreter::filterByValue):
(JSC::DFG::AbstractInterpreter::trySetConstant):
(JSC::DFG::AbstractInterpreter::filterByType):
* dfg/DFGAbstractInterpreterInlines.h: Added.
(DFG):
(JSC::DFG::::AbstractInterpreter):
(JSC::DFG::::~AbstractInterpreter):
(JSC::DFG::::booleanResult):
(JSC::DFG::::startExecuting):
(JSC::DFG::::executeEdges):
(JSC::DFG::::verifyEdge):
(JSC::DFG::::verifyEdges):
(JSC::DFG::::executeEffects):
(JSC::DFG::::execute):
(JSC::DFG::::clobberWorld):
(JSC::DFG::::clobberCapturedVars):
(JSC::DFG::::clobberStructures):
(JSC::DFG::::dump):
(JSC::DFG::::filter):
(JSC::DFG::::filterArrayModes):
(JSC::DFG::::filterByValue):
* dfg/DFGAbstractState.cpp: Removed.
* dfg/DFGAbstractState.h: Removed.
* dfg/DFGArgumentsSimplificationPhase.cpp:
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::CFAPhase):
(JSC::DFG::CFAPhase::performBlockCFA):
(CFAPhase):
* dfg/DFGCFGSimplificationPhase.cpp:
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase):
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(ConstantFoldingPhase):
* dfg/DFGInPlaceAbstractState.cpp: Added.
(DFG):
(JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::~InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::beginBasicBlock):
(JSC::DFG::setLiveValues):
(JSC::DFG::InPlaceAbstractState::initialize):
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
(JSC::DFG::InPlaceAbstractState::reset):
(JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
(JSC::DFG::InPlaceAbstractState::merge):
(JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
(JSC::DFG::InPlaceAbstractState::mergeVariableBetweenBlocks):
* dfg/DFGInPlaceAbstractState.h: Added.
(DFG):
(InPlaceAbstractState):
(JSC::DFG::InPlaceAbstractState::forNode):
(JSC::DFG::InPlaceAbstractState::variables):
(JSC::DFG::InPlaceAbstractState::block):
(JSC::DFG::InPlaceAbstractState::didClobber):
(JSC::DFG::InPlaceAbstractState::isValid):
(JSC::DFG::InPlaceAbstractState::setDidClobber):
(JSC::DFG::InPlaceAbstractState::setIsValid):
(JSC::DFG::InPlaceAbstractState::setBranchDirection):
(JSC::DFG::InPlaceAbstractState::setFoundConstants):
(JSC::DFG::InPlaceAbstractState::haveStructures):
(JSC::DFG::InPlaceAbstractState::setHaveStructures):
* dfg/DFGMergeMode.h: Added.
(DFG):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::backwardTypeCheck):
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::compileToStringOnCell):
(JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
(JSC::DFG::SpeculativeJIT::speculateStringObject):
(JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::needsTypeCheck):
(SpeculativeJIT):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
(JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
* ftl/FTLLowerDFGToLLVM.cpp:
(FTL):
(JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
(JSC::FTL::LowerDFGToLLVM::speculate):
(JSC::FTL::LowerDFGToLLVM::speculateNumber):
(JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
(LowerDFGToLLVM):

Conflicts:
	Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153282 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: AbstractInterpreter should explicitly ask AbstractState to create new AbstractValues for newly born nodes
https://bugs.webkit.org/show_bug.cgi?id=118880

Reviewed by Sam Weinig.

It should be possible to have an AbstractState that is backed by a HashMap. But to
do this, the AbstractInterpreter should explicitly ask for new nodes to be added to
the map, since otherwise the idiom of getting a reference to the AbstractValue
returned by forNode() would cause really subtle memory corruption bugs.

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGInPlaceAbstractState.h:
(JSC::DFG::InPlaceAbstractState::createValueForNode):
(InPlaceAbstractState):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153283 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: Structure should be able to tell you if it's valid to load at a given offset from any object with that structure
https://bugs.webkit.org/show_bug.cgi?id=118878

Reviewed by Oliver Hunt.

- Change Structure::isValidOffset() to actually answer the question "If I attempted
  to load from an object of this structure, at this offset, would I commit suicide
  or would I get back some kind of value?"

- Change StorageAccessData::offset to use a PropertyOffset. It should have been that
  way from the start.

- Fix PutStructure so that it sets haveStructures in all of the cases that it should.

- Make GetByOffset also reference the base object in addition to the butterfly.

The future use of this power will be to answer questions like "If I hoisted this
GetByOffset or PutByOffset to this point, would it cause crashes, or would it be
fine?"

I don't currently plan to use this power to perform validation, since the CSE has
the power to eliminate CheckStructure's that the CFA wouldn't be smart enough to
remove - both in the case of StructureSets where size >= 2 and in the case of
CheckStructures that match across PutStructures. At first I tried to write a
validator that was aware of this, but the validation code got way too complicated
and I started having nightmares of spurious assertion bugs being filed against me.

This also changes some of the code for how we hash FunctionExecutable's for debug
dumps, since that code still had some thread-safety issues. Basically, the
concurrent JIT needs to use the CodeBlock's precomputed hash and never call anything
that could transitively try to compute the hash from the source code. The source
code is a string that may be lazily computed, and that involves all manner of thread
unsafe things.

* bytecode/CodeOrigin.cpp:
(JSC::InlineCallFrame::hash):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleGetByOffset):
(JSC::DFG::ByteCodeParser::handlePutByOffset):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(StorageAccessData):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToGetByOffset):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
(JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
* runtime/FunctionExecutableDump.cpp:
(JSC::FunctionExecutableDump::dump):
* runtime/Structure.h:
(Structure):
(JSC::Structure::isValidOffset):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153284 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: Structure::isValidOffset() should be able to tell you if you're loading a valid JSValue, and not just not crashing
https://bugs.webkit.org/show_bug.cgi?id=118911

Reviewed by Geoffrey Garen.

We could also have a separate method like "willNotCrash(offset)", but that's not
what isValidOffset() is intended to mean.

* runtime/Structure.h:
(JSC::Structure::isValidOffset):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153285 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: String GetByVal out-of-bounds handling is so wrong
https://bugs.webkit.org/show_bug.cgi?id=118935

Source/JavaScriptCore:

Reviewed by Geoffrey Garen.

Bunch of String GetByVal out-of-bounds fixes:

- Even if the string proto chain is sane, we need to watch out for negative
  indices. They may get values or call getters in the prototypes, since proto
  sanity doesn't check for negative indexed properties, as they are not
  technically indexed properties.

- GetByVal String out-of-bounds does in fact clobberWorld(). CSE should be
  given this information.

- GetByVal String out-of-bounds does in fact clobberWorld(). CFA should be
  given this information.

Also fixed some other things:

- If the DFG is disabled, the testRunner should pretend that we've done a
  bunch of DFG compiles. That's necessary to prevent the tests from timing
  out.

- Disassembler shouldn't try to dump source code since it's not safe in the
  concurrent JIT.

* API/JSCTestRunnerUtils.cpp:
(JSC::numberOfDFGCompiles):
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::dumpHeader):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::byValIsPure):
* dfg/DFGSaneStringGetByValSlowPathGenerator.h: Added.
(DFG):
(SaneStringGetByValSlowPathGenerator):
(JSC::DFG::SaneStringGetByValSlowPathGenerator::SaneStringGetByValSlowPathGenerator):
(JSC::DFG::SaneStringGetByValSlowPathGenerator::generateInternal):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):

LayoutTests:

Reviewed by Geoffrey Garen.

* fast/js/dfg-string-out-of-bounds-check-structure-expected.txt: Added.
* fast/js/dfg-string-out-of-bounds-check-structure.html: Added.
* fast/js/dfg-string-out-of-bounds-cse-expected.txt: Added.
* fast/js/dfg-string-out-of-bounds-cse.html: Added.
* fast/js/dfg-string-out-of-bounds-negative-check-structure-expected.txt: Added.
* fast/js/dfg-string-out-of-bounds-negative-check-structure.html: Added.
* fast/js/dfg-string-out-of-bounds-negative-proto-value-expected.txt: Added.
* fast/js/dfg-string-out-of-bounds-negative-proto-value.html: Added.
* fast/js/jsc-test-list:
* fast/js/script-tests/dfg-string-out-of-bounds-check-structure.js: Added.
(foo):
* fast/js/script-tests/dfg-string-out-of-bounds-cse.js: Added.
(foo):
* fast/js/script-tests/dfg-string-out-of-bounds-negative-check-structure.js: Added.
(foo):
(while):
* fast/js/script-tests/dfg-string-out-of-bounds-negative-proto-value.js: Added.
(foo):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153286 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: StringObjectUse uses structures, and CSE should know that
https://bugs.webkit.org/show_bug.cgi?id=118940

Reviewed by Geoffrey Garen.

This is asymptomatic right now, but we should fix it.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::putStructureStoreElimination):
* dfg/DFGEdgeUsesStructure.h: Added.
(DFG):
(EdgeUsesStructure):
(JSC::DFG::EdgeUsesStructure::EdgeUsesStructure):
(JSC::DFG::EdgeUsesStructure::operator()):
(JSC::DFG::EdgeUsesStructure::result):
(JSC::DFG::edgesUseStructure):
* dfg/DFGUseKind.h:
(DFG):
(JSC::DFG::usesStructure):

Conflicts:
	Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153287 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: We should use the no-asserts build of LLVM if that's what the user configured
https://bugs.webkit.org/show_bug.cgi?id=118947

Reviewed by Dan Bernstein.

* Scripts/copy-webkitlibraries-to-product-directory:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153288 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: FTL should be able to generate LLVM IR that uses an intrinsic for OSR exit
https://bugs.webkit.org/show_bug.cgi?id=118948

Source/JavaScriptCore:

Reviewed by Sam Weinig.

- Add the ability to generate LLVM IR but then not use it, via --llvmAlwaysFails=true.
  This allows doing "what if" experiments with IR generation, even if the generated IR
  can't yet execute.

- Add an OSR exit path that just calls an intrinsic that combines the branch and the
  off-ramp.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* ftl/FTLFail.cpp: Added.
(FTL):
(JSC::FTL::fail):
* ftl/FTLFail.h: Added.
(FTL):
* ftl/FTLIntrinsicRepository.h:
(FTL):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
* runtime/Options.h:
(JSC):

Tools:

Reviewed by Sam Weinig.

- Make ReducedFTL capable of dealing with code that uses the fake OSR exit intrinsic,
  by exporting it as a function.

- Make combineModules.rb idempotent. Sometimes it's convenient to run a file through
  it even if you know that you've already done so. See processIRDump.sh.

- Add a script, processIRDump.sh, that takes the output of --dumpLLVMIR=true and
  runs it through ReducedFTL automatically. You typically want to say something like:

  jsc --dumpLLVMIR=true <program(s)> > jsc-output.txt
  ./processIRDump.sh --timing < jsc-output.txt

* ReducedFTL/ReducedFTL.c:
(webkit_osr_exit):
* ReducedFTL/combineModules.rb:
* ReducedFTL/processIRDump.sh: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153289 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: each DFG node that relies on other nodes to do their type checks should be able to tell you if those type checks happened
https://bugs.webkit.org/show_bug.cgi?id=118866

Reviewed by Sam Weinig.

Adds a safeToExecute() method that takes a node and an abstract state and tells you
if the node will run without crashing under that state.

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
* dfg/DFGCFAPhase.cpp:
(CFAPhase):
(JSC::DFG::CFAPhase::CFAPhase):
(JSC::DFG::CFAPhase::run):
(JSC::DFG::CFAPhase::performBlockCFA):
(JSC::DFG::CFAPhase::performForwardCFA):
* dfg/DFGSafeToExecute.h: Added.
(DFG):
(SafeToExecuteEdge):
(JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge):
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::SafeToExecuteEdge::result):
(JSC::DFG::safeToExecute):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::isValidOffset):
(StructureAbstractValue):
* runtime/Options.h:
(JSC):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153290 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: It should be possible for a DFG::Node to claim to exit to one CodeOrigin, but then claim that it belongs to a different CodeOrigin for all other purposes
https://bugs.webkit.org/show_bug.cgi?id=118946

Reviewed by Geoffrey Garen.

We want to decouple the exit target code origin of a node from the code origin
for all other purposes. The purposes of code origins are:

- Where the node will exit, if it exits. The exit target should be consistent with
  the surrounding nodes, in that if you just looked at the code origins of nodes in
  the graph, they would be consistent with the code origins in bytecode. This is
  necessary for live-at-bytecode analyses to work, and to preserve the original
  bytecode semantics when exiting.

- What kind of code the node came from, for semantics thingies. For example, we
  might use the code origin to find the node's global object for doing an original
  array check. Or we might use it to determine if the code is in strict mode. Or
  other similar things. When we use the code origin in this way, we're basically
  using it as a way of describing the node's meta-data without putting it into the
  node directly, to save space. In the absurd extreme you could imagine nodes not
  even having NodeTypes or NodeFlags, and just using the CodeOrigin to determine
  what bytecode the node originated from. We won't do that, but you can think of
  this use of code origins as just a way of compressing meta-data.

- What code origin we should supply profiling to, if we exit. This is closely
  related to the semantics thingies, in that the exit profiling is a persistent
  kind of semantic meta-data that survives between recompiles, and the only way to
  do that is to ascribe it to the original bytecode via the code origin.

If we hoist a node, we need to change the exit target code origin, but we must not
change the code origin for other purposes. The best way to do this is to decouple
the two kinds of code origin.

OSR exit data structures already do this, because they may edit the exit target
code origin while keeping the code origin for profiling intact. This happens for
forward exits. So, we just need to thread separation all the way back to DFG::Node.
That's what this patch does.

* dfg/DFGNode.h:
(JSC::DFG::Node::Node):
(Node):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::OSRExitBase):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* dfg/DFGSpeculativeJIT.h:
(SpeculativeJIT):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::appendOSRExit):
(LowerDFGToLLVM):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExit::OSRExit):
* ftl/FTLOSRExit.h:
(OSRExit):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153291 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: NodeExitsForward shouldn't be duplicated in NodeType
https://bugs.webkit.org/show_bug.cgi?id=118956

Reviewed by Sam Weinig.

We had two way of expressing that something exits forward: the NodeExitsForward
flag and the word 'Forward' in the NodeType. That's kind of dumb. This patch
makes it just be a flag.

* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
* dfg/DFGArgumentsSimplificationPhase.cpp:
(JSC::DFG::ArgumentsSimplificationPhase::run):
* dfg/DFGCSEPhase.cpp:
(JSC::DFG::CSEPhase::int32ToDoubleCSE):
(JSC::DFG::CSEPhase::checkStructureElimination):
(JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
(JSC::DFG::CSEPhase::putStructureStoreElimination):
(JSC::DFG::CSEPhase::checkArrayElimination):
(JSC::DFG::CSEPhase::performNodeCSE):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
* dfg/DFGMinifiedNode.h:
(JSC::DFG::belongsInMinifiedGraph):
(JSC::DFG::MinifiedNode::hasChild):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToStructureTransitionWatchpoint):
(JSC::DFG::Node::hasStructureSet):
(JSC::DFG::Node::hasStructure):
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::willHaveCodeGenOrOSR):
* dfg/DFGNodeType.h:
(DFG):
(JSC::DFG::needsOSRForwardRewiring):
* dfg/DFGPredictionPropagationPhase.cpp:
(JSC::DFG::PredictionPropagationPhase::propagate):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::run):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* dfg/DFGVariableEventStream.cpp:
(JSC::DFG::VariableEventStream::reconstruct):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToLLVM.cpp:
(JSC::FTL::LowerDFGToLLVM::compileNode):
(JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153292 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: It should be easy to figure out which blocks nodes belong to
https://bugs.webkit.org/show_bug.cgi?id=118957

Reviewed by Sam Weinig.

* dfg/DFGGraph.cpp:
(DFG):
(JSC::DFG::Graph::initializeNodeOwners):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGNode.h:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153293 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG Nodes should be able to abstractly tell you what they read and what they write
https://bugs.webkit.org/show_bug.cgi?id=118910

Source/JavaScriptCore:

Reviewed by Sam Weinig.

Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in
the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are
engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to
be inexpensive to use (they just give you a TBAA node) but expensive to create (you
create them all up front). FTL AbstractHeaps also don't actually give you the
ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA.
The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use.
They also give you aliasing machinery. The DFG AbstractHeaps are represented
internally by a int64_t. Many comparisons between them are just integer comaprisons.
AbstractHeaps form a three-level hierarchy (World is the supertype of everything,
Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP
payload is the direct subtype of its corresponding TOP Kind).

Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had
clobbered. It represents the set that results from unifying a bunch of
AbstractHeaps, and is intended to quickly answer overlap questions: does the given
AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an
AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of
its ancestors. An AbstractHeap is said to overlap a set if any direct or super
member is equal to it, or if any of its ancestors are equal to a direct member.

Example #1:

    - I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This
      is a subtype of Variables, which is a subtype of World.
    - You query Variables. I.e. Variables with a TOP payload, which is the
      supertype of Variables(X) for any X, and a subtype of World.

    The set will have Variables(5) as a direct member, and Variables and World as
    super members. The Variables query will immediately return true, because
    Variables is indeed a super member.

Example #2:

    - I add Variables(5)
    - You query NamedProperties

    NamedProperties is not a member at all (neither direct or super). We next
    query World. World is a member, but it's a super member, so we return false.

Example #3:

    - I add Variables
    - You query Variables(5)

    The set will have Variables as a direct member, and World as a super member.
    The Variables(5) query will not find Variables(5) in the set, but then it
    will query Variables. Variables is a direct member, so we return true.

Example #4:

    - I add Variables
    - You query NamedProperties(5)

    Neither NamedProperties nor NamedProperties(5) are members. We next query
    World. World is a member, but it's a super member, so we return false.

Overlap queries require that either the heap being queried is in the set (either
direct or super), or that one of its ancestors is a direct member. Another way to
think about how this works is that two heaps A and B are said to overlap if
A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a
single-inheritance heirarchy. Consider that we wanted to implement a set that holds
heaps and answers the question, "is any member in the set an ancestor (i.e.
supertype) of some other heap". We would have the set contain the heaps themselves,
and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor
chain of A, and repeatedly querying its membership in the set. This is what the
"direct" members of our set do. Now consider the other part, where we want to ask if
any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We
would implement this by implementing set.add(B) as adding not just B but also all of
B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is
in the set. With two such sets - one that answers isSubtypeOfAny() and another that
answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your
heap" question. ClobberSet does this, but combines the two sets into a single
HashMap. The HashMap's value, "direct", means that the key is a member of both the
supertype set and the subtype set; if it's false then it's only a member of one of
them.

Finally, this adds a functorized clobberize() method that adds the read and write
clobbers of a DFG::Node to read and write functors. Common functors for adding to
ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers
are also provided. This allows you to say things like:

    ClobberSet set;
    addWrites(graph, node1, set);
    if (readsOverlap(graph, node2, set))
        // We know that node1 may write to something that node2 may read from.

Currently this facility is only used to improve graph dumping, but it will be
instrumental in both LICM and GVN. In the future, I want to completely kill the
NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way
of accomplishing almost exactly what AbstractHeap gives you.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractHeap.cpp: Added.
(DFG):
(JSC::DFG::AbstractHeap::Payload::dump):
(JSC::DFG::AbstractHeap::dump):
(WTF):
(WTF::printInternal):
* dfg/DFGAbstractHeap.h: Added.
(DFG):
(AbstractHeap):
(Payload):
(JSC::DFG::AbstractHeap::Payload::Payload):
(JSC::DFG::AbstractHeap::Payload::top):
(JSC::DFG::AbstractHeap::Payload::isTop):
(JSC::DFG::AbstractHeap::Payload::value):
(JSC::DFG::AbstractHeap::Payload::valueImpl):
(JSC::DFG::AbstractHeap::Payload::operator==):
(JSC::DFG::AbstractHeap::Payload::operator!=):
(JSC::DFG::AbstractHeap::Payload::operator<):
(JSC::DFG::AbstractHeap::Payload::isDisjoint):
(JSC::DFG::AbstractHeap::Payload::overlaps):
(JSC::DFG::AbstractHeap::AbstractHeap):
(JSC::DFG::AbstractHeap::operator!):
(JSC::DFG::AbstractHeap::kind):
(JSC::DFG::AbstractHeap::payload):
(JSC::DFG::AbstractHeap::isDisjoint):
(JSC::DFG::AbstractHeap::overlaps):
(JSC::DFG::AbstractHeap::supertype):
(JSC::DFG::AbstractHeap::hash):
(JSC::DFG::AbstractHeap::operator==):
(JSC::DFG::AbstractHeap::operator!=):
(JSC::DFG::AbstractHeap::operator<):
(JSC::DFG::AbstractHeap::isHashTableDeletedValue):
(JSC::DFG::AbstractHeap::payloadImpl):
(JSC::DFG::AbstractHeap::encode):
(JSC::DFG::AbstractHeapHash::hash):
(JSC::DFG::AbstractHeapHash::equal):
(AbstractHeapHash):
(WTF):
* dfg/DFGClobberSet.cpp: Added.
(DFG):
(JSC::DFG::ClobberSet::ClobberSet):
(JSC::DFG::ClobberSet::~ClobberSet):
(JSC::DFG::ClobberSet::add):
(JSC::DFG::ClobberSet::addAll):
(JSC::DFG::ClobberSet::contains):
(JSC::DFG::ClobberSet::overlaps):
(JSC::DFG::ClobberSet::clear):
(JSC::DFG::ClobberSet::direct):
(JSC::DFG::ClobberSet::super):
(JSC::DFG::ClobberSet::dump):
(JSC::DFG::ClobberSet::setOf):
(JSC::DFG::addReads):
(JSC::DFG::addWrites):
(JSC::DFG::addReadsAndWrites):
(JSC::DFG::readsOverlap):
(JSC::DFG::writesOverlap):
* dfg/DFGClobberSet.h: Added.
(DFG):
(ClobberSet):
(JSC::DFG::ClobberSet::isEmpty):
(ClobberSetAdd):
(JSC::DFG::ClobberSetAdd::ClobberSetAdd):
(JSC::DFG::ClobberSetAdd::operator()):
(ClobberSetOverlaps):
(JSC::DFG::ClobberSetOverlaps::ClobberSetOverlaps):
(JSC::DFG::ClobberSetOverlaps::operator()):
(JSC::DFG::ClobberSetOverlaps::result):
* dfg/DFGClobberize.cpp: Added.
(DFG):
(JSC::DFG::didWrites):
* dfg/DFGClobberize.h: Added.
(DFG):
(JSC::DFG::clobberize):
(NoOpClobberize):
(JSC::DFG::NoOpClobberize::NoOpClobberize):
(JSC::DFG::NoOpClobberize::operator()):
(CheckClobberize):
(JSC::DFG::CheckClobberize::CheckClobberize):
(JSC::DFG::CheckClobberize::operator()):
(JSC::DFG::CheckClobberize::result):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dump):

Source/WTF:

Reviewed by Sam Weinig.

Fix compile goof in sortedListDump().

* wtf/ListDump.h:
(WTF::sortedListDump):

Conflicts:
	Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153294 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG should do a high-level LICM before going to FTL
https://bugs.webkit.org/show_bug.cgi?id=118749

Reviewed by Oliver Hunt.

Implements LICM hoisting for nodes that never write anything and never read
things that are clobbered by the loop. There are some other preconditions for
hoisting, see DFGLICMPhase.cpp.

Also did a few fixes:

- ClobberSet::add was failing to switch Super entries to Direct entries in
  some cases.

- DFGClobberize.cpp needed to #include "Operations.h".

- DCEPhase needs to process the graph in reverse DFS order, when we're in SSA.

- AbstractInterpreter can now execute a Node without knowing its indexInBlock.
  Knowing the indexInBlock is an optional optimization that all other clients
  of AI still opt into, but LICM doesn't.

This makes the FTL a 2.19x speed-up on imaging-gaussian-blur.

* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreter.h:
(AbstractInterpreter):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::::executeEffects):
(JSC::DFG::::execute):
(DFG):
(JSC::DFG::::clobberWorld):
(JSC::DFG::::clobberStructures):
* dfg/DFGAtTailAbstractState.cpp: Added.
(DFG):
(JSC::DFG::AtTailAbstractState::AtTailAbstractState):
(JSC::DFG::AtTailAbstractState::~AtTailAbstractState):
(JSC::DFG::AtTailAbstractState::createValueForNode):
(JSC::DFG::AtTailAbstractState::forNode):
* dfg/DFGAtTailAbstractState.h: Added.
(DFG):
(AtTailAbstractState):
(JSC::DFG::AtTailAbstractState::initializeTo):
(JSC::DFG::AtTailAbstractState::forNode):
(JSC::DFG::AtTailAbstractState::variables):
(JSC::DFG::AtTailAbstractState::block):
(JSC::DFG::AtTailAbstractState::isValid):
(JSC::DFG::AtTailAbstractState::setDidClobber):
(JSC::DFG::AtTailAbstractState::setIsValid):
(JSC::DFG::AtTailAbstractState::setBranchDirection):
(JSC::DFG::AtTailAbstractState::setFoundConstants):
(JSC::DFG::AtTailAbstractState::haveStructures):
(JSC::DFG::AtTailAbstractState::setHaveStructures):
* dfg/DFGBasicBlock.h:
(JSC::DFG::BasicBlock::insertBeforeLast):
* dfg/DFGBasicBlockInlines.h:
(DFG):
* dfg/DFGClobberSet.cpp:
(JSC::DFG::ClobberSet::add):
(JSC::DFG::ClobberSet::addAll):
* dfg/DFGClobberize.cpp:
(JSC::DFG::doesWrites):
* dfg/DFGClobberize.h:
(DFG):
* dfg/DFGDCEPhase.cpp:
(JSC::DFG::DCEPhase::DCEPhase):
(JSC::DFG::DCEPhase::run):
(JSC::DFG::DCEPhase::fixupBlock):
(DCEPhase):
* dfg/DFGEdgeDominates.h: Added.
(DFG):
(EdgeDominates):
(JSC::DFG::EdgeDominates::EdgeDominates):
(JSC::DFG::EdgeDominates::operator()):
(JSC::DFG::EdgeDominates::result):
(JSC::DFG::edgesDominate):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::checkArray):
* dfg/DFGLICMPhase.cpp: Added.
(LICMPhase):
(JSC::DFG::LICMPhase::LICMPhase):
(JSC::DFG::LICMPhase::run):
(JSC::DFG::LICMPhase::attemptHoist):
(DFG):
(JSC::DFG::performLICM):
* dfg/DFGLICMPhase.h: Added.
(DFG):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153295 268f45cc-cd09-0410-ab3c-d52691b4dbfc
fourthTier: DFG IR dumps should be easier to read
https://bugs.webkit.org/show_bug.cgi?id=119050

Source/JavaScriptCore:

Reviewed by Mark Hahnenberg.

Added a DumpContext that includes support for printing an endnote
that describes all structures in full, while the main flow of the
dump just uses made-up names for the structures. This is helpful
since Structure::dump() may print a lot. The stuff it prints is
useful, but if it's all inline with the surrounding thing you're
dumping (often, a node in the DFG), then you get a ridiculously
long print-out. All classes that dump structures (including
Structure itself) now have dumpInContext() methods that use
inContext() for dumping anything that might transitively print a
structure. If Structure::dumpInContext() is called with a NULL
context, it just uses dump() like before. Hence you don't have to
know anything about DumpContext unless you want to.

inContext(*structure, context) dumps something like %B4:Array,
and the endnote will have something like:

    %B4:Array    = 0x10e91a180:[Array, {Edge:100, Normal:101, Line:102, NumPx:103, LastPx:104}, ArrayWithContiguous, Proto:0x10e99ffe0]

where B4 is the inferred name that StringHashDumpContext came up
with.

Also shortened a bunch of other dumps, removing information that
isn't so important.

* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/ArrayProfile.cpp:
(JSC::dumpArrayModes):
* bytecode/CodeBlockHash.cpp:
(JSC):
(JSC::CodeBlockHash::CodeBlockHash):
(JSC::CodeBlockHash::dump):
* bytecode/CodeOrigin.cpp:
(JSC::CodeOrigin::dumpInContext):
(JSC):
(JSC::InlineCallFrame::dumpInContext):
(JSC::InlineCallFrame::dump):
* bytecode/CodeOrigin.h:
(CodeOrigin):
(InlineCallFrame):
* bytecode/Operands.h:
(JSC::OperandValueTraits::isEmptyForDump):
(Operands):
(JSC::Operands::dump):
(JSC):
* bytecode/OperandsInlines.h: Added.
(JSC):
(JSC::::dumpInContext):
* bytecode/StructureSet.h:
(JSC::StructureSet::dumpInContext):
(JSC::StructureSet::dump):
(StructureSet):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::dump):
(DFG):
(JSC::DFG::AbstractValue::dumpInContext):
* dfg/DFGAbstractValue.h:
(JSC::DFG::AbstractValue::operator!):
(AbstractValue):
* dfg/DFGCFAPhase.cpp:
(JSC::DFG::CFAPhase::performBlockCFA):
* dfg/DFGCommon.cpp:
* dfg/DFGCommon.h:
(JSC::DFG::NodePointerTraits::isEmptyForDump):
* dfg/DFGDisassembler.cpp:
(JSC::DFG::Disassembler::createDumpList):
* dfg/DFGDisassembler.h:
(Disassembler):
* dfg/DFGFlushFormat.h:
(WTF::inContext):
(WTF):
* dfg/DFGFlushLivenessAnalysisPhase.cpp:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::dumpCodeOrigin):
(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::dumpBlockHeader):
* dfg/DFGGraph.h:
(Graph):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::dumpInContext):
(JSC::DFG::LazyJSValue::dump):
(DFG):
* dfg/DFGLazyJSValue.h:
(LazyJSValue):
* dfg/DFGNode.h:
(JSC::DFG::nodeMapDump):
(WTF::inContext):
(WTF):
* dfg/DFGOSRExitCompiler32_64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGOSRExitCompiler64.cpp:
(JSC::DFG::OSRExitCompiler::compileExit):
* dfg/DFGStructureAbstractValue.h:
(JSC::DFG::StructureAbstractValue::dumpInContext):
(JSC::DFG::StructureAbstractValue::dump):
(StructureAbstractValue):
* ftl/FTLExitValue.cpp:
(JSC::FTL::ExitValue::dumpInContext):
(JSC::FTL::ExitValue::dump):
(FTL):
* ftl/FTLExitValue.h:
(ExitValue):
* ftl/FTLLowerDFGToLLVM.cpp:
* ftl/FTLValueSource.cpp:
(JSC::FTL::ValueSource::dumpInContext):
(FTL):
* ftl/FTLValueSource.h:
(ValueSource):
* runtime/DumpContext.cpp: Added.
(JSC):
(JSC::DumpContext::DumpContext):
(JSC::DumpContext::~DumpContext):
(JSC::DumpContext::isEmpty):
(JSC::DumpContext::dump):
* runtime/DumpContext.h: Added.
(JSC):
(DumpContext):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dump):
(JSC):
(JSC::JSValue::dumpInContext):
* runtime/JSCJSValue.h:
(JSC):
(JSValue):
* runtime/Structure.cpp:
(JSC::Structure::dumpInContext):
(JSC):
(JSC::Structure::dumpBrief):
(JSC::Structure::dumpContextHeader):
* runtime/Structure.h:
(JSC):
(Structure):

Source/WTF:

Reviewed by Mark Hahnenberg.

Added support for dumping values within a context. By default, if you say
print(inContext(value, context)) it calls value.dumpInContext(out, context)
instead of value.dump(out).

Hoisted the support for six-character hashes out of JSC::CodeBlockHash into
WTF, in the form of SixCharacterHash.h.

Added a helper for creating dump contexts where the inContext() dump will
just use a short string hash to "name" the object being dumped, and then
will print out the full dumps in an endnote to your dump.

Added support for using CString as a hashtable key.

* WTF.xcodeproj/project.pbxproj:
* wtf/PrintStream.h:
(WTF):
(ValueInContext):
(WTF::ValueInContext::ValueInContext):
(WTF::ValueInContext::dump):
(WTF::inContext):
* wtf/SixCharacterHash.cpp: Added.
(WTF):
(WTF::sixCharacterHashStringToInteger):
(WTF::integerToSixCharacterHashString):
* wtf/SixCharacterHash.h: Added.
(WTF):
* wtf/StringHashDumpContext.h: Added.
(WTF):
(StringHashDumpContext):
(WTF::StringHashDumpContext::StringHashDumpContext):
(WTF::StringHashDumpContext::getID):
(WTF::StringHashDumpContext::dumpBrief):
(WTF::StringHashDumpContext::brief):
(WTF::StringHashDumpContext::isEmpty):
(WTF::StringHashDumpContext::dump):
* wtf/text/CString.cpp:
(WTF::CString::hash):
(WTF):
(WTF::operator<):
(WTF::CStringHash::equal):
* wtf/text/CString.h:
(WTF::CString::CString):
(CString):
(WTF::CString::isHashTableDeletedValue):
(WTF):
(WTF::CStringHash::hash):
(CStringHash):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153296 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Introduce toSVGPatternElement(), use it
https://bugs.webkit.org/show_bug.cgi?id=119013

Reviewed by Andreas Kling.

As a step to change static_cast with toSVGXXX, static_cast<SVGPatternElement*> can
be changed with toSVGPatternElement().

Merge from https://src.chromium.org/viewvc/blink?view=rev&revision=154734

* rendering/svg/RenderSVGResourcePattern.cpp:
(WebCore::RenderSVGResourcePattern::buildPattern):
* rendering/svg/SVGRenderTreeAsText.cpp:
(WebCore::writeSVGResourceContainer):
* rendering/svg/SVGResources.cpp:
(WebCore::targetReferenceFromResource):
* svg/SVGPatternElement.h:
(WebCore::toSVGPatternElement):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153297 268f45cc-cd09-0410-ab3c-d52691b4dbfc