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
Endeavour to fix CMakelist builds

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153298 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed buildfix after FTL upstream for non C++11 builds.

* interpreter/CallFrame.h:
* interpreter/StackIteratorPrivate.h:
(JSC::StackIterator::end):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153299 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed buildfix after FTL upstream.

Add ftl directory as include path.

* CMakeLists.txt:
* JavaScriptCore.pri:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153300 268f45cc-cd09-0410-ab3c-d52691b4dbfc
One more fix after FTL upstream.

* Target.pri:
* bytecode/CodeBlock.h:
* bytecode/GetByIdStatus.h:
(JSC::GetByIdStatus::GetByIdStatus):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153301 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed buildfix after FTL upstream.

* runtime/JSScope.h:
(JSC::needsVarInjectionChecks):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153302 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Fixing the GTK build after the FTL merging by updating the build targets list.

* GNUmakefile.am:
* GNUmakefile.list.am:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153303 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Build break in debug after r153134: StringImpl.h:640: undefined reference to `WTF::isCompilationThread()
https://bugs.webkit.org/show_bug.cgi?id=119077

Reviewed by Christophe Dumez.

* wtf/CMakeLists.txt:
Added CompilationThread.{h/cpp}.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153304 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed. Further build fixing for the GTK port. Adding the forwarding header
for JSCTestRunnerUtils.h as required by the DumpRenderTree compilation.

* ForwardingHeaders/JavaScriptCore/JSCTestRunnerUtils.h: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153305 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed GTK build fix.

* GNUmakefile.list.am: Adding JSCTestRunnerUtils files to the build.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153306 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Fix "Unhandled opcode localAnnotation" build error in sh4 and mips LLINT.
https://bugs.webkit.org/show_bug.cgi?id=119076

Patch by Julien Brianceau <jbrianceau@nds.com> on 2013-07-25
Reviewed by Allan Sandfeld Jensen.

* offlineasm/mips.rb:
* offlineasm/sh4.rb:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153307 268f45cc-cd09-0410-ab3c-d52691b4dbfc
One more buildfix after FTL upstream.

Return a dummy value after RELEASE_ASSERT_NOT_REACHED() to make GCC happy.

* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::LazyJSValue::getValue):
(JSC::DFG::LazyJSValue::strictEqual):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153308 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] Similar fix to r153304.

* GNUmakefile.list.am:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@153309 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Buildfix after this error:
error: 'pathName' may be used uninitialized in this function [-Werror=uninitialized]

* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThread):

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