Reduce JSC API static value setter/getter overhead.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2013-07-31  Yi Shen  <max.hong.shen@gmail.com>
2
3         Reduce JSC API static value setter/getter overhead.
4         https://bugs.webkit.org/show_bug.cgi?id=119277
5
6         Reviewed by Geoffrey Garen.
7
8         Add property name to the static value entry, so that OpaqueJSString::create() doesn't
9         need to get called every time when set or get the static value.
10
11         * API/JSCallbackObjectFunctions.h:
12         (JSC::::put):
13         (JSC::::putByIndex):
14         (JSC::::getStaticValue):
15         * API/JSClassRef.cpp:
16         (OpaqueJSClassContextData::OpaqueJSClassContextData):
17         * API/JSClassRef.h:
18         (StaticValueEntry::StaticValueEntry):
19
20 2013-07-31  Kwang Yul Seo  <skyul@company100.net>
21
22         Use emptyString instead of String("")
23         https://bugs.webkit.org/show_bug.cgi?id=119335
24
25         Reviewed by Darin Adler.
26
27         Use emptyString() instead of String("") because it is better style and
28         faster. This is a followup to r116908, removing all occurrences of
29         String("") from WebKit.
30
31         * runtime/RegExpConstructor.cpp:
32         (JSC::constructRegExp):
33         * runtime/RegExpPrototype.cpp:
34         (JSC::regExpProtoFuncCompile):
35         * runtime/StringPrototype.cpp:
36         (JSC::stringProtoFuncMatch):
37         (JSC::stringProtoFuncSearch):
38
39 2013-07-31  Ruth Fong  <ruth_fong@apple.com>
40
41         <input type=color> Mac UI behaviour
42         <rdar://problem/10269922> and https://bugs.webkit.org/show_bug.cgi?id=61276
43
44         Reviewed by Brady Eidson.
45
46         * Configurations/FeatureDefines.xcconfig: Enabled INPUT_TYPE_COLOR.
47
48 2013-07-31  Mark Hahnenberg  <mhahnenberg@apple.com>
49
50         DFG doesn't account for inlining of functions with switch statements that haven't been executed by the baseline JIT
51         https://bugs.webkit.org/show_bug.cgi?id=119349
52
53         Reviewed by Geoffrey Garen.
54
55         Prior to this patch, the baseline JIT was responsible for resizing the ctiOffsets Vector for 
56         SimpleJumpTables to be equal to the size of the branchOffsets Vector. The DFG implicitly relied
57         on code it compiled with any switch statements to have been run in the baseline JIT first. 
58         However, if the DFG chooses to inline a function that has never been compiled by the baseline 
59         JIT then this resizing never happens and we crash at link time in the DFG.
60
61         We can fix this by also doing the resize in the DFG to catch this case.
62
63         * dfg/DFGJITCompiler.cpp:
64         (JSC::DFG::JITCompiler::link):
65
66 2013-07-31  Gavin Barraclough  <barraclough@apple.com>
67
68         Speculative Windows build fix.
69
70         Reviewed by NOBODY
71
72         * runtime/JSString.cpp:
73         (JSC::JSRopeString::getIndexSlowCase):
74         * runtime/JSString.h:
75
76 2013-07-30  Gavin Barraclough  <barraclough@apple.com>
77
78         Some cleanup in JSValue::get
79         https://bugs.webkit.org/show_bug.cgi?id=119343
80
81         Reviewed by Geoff Garen.
82
83         JSValue::get is implemented to:
84             1) Check if the value is a cell – if not, synthesize a prototype to search,
85             2) call getOwnPropertySlot on the cell,
86             3) if this returns false, cast to JSObject to get the prototype, and walk the prototype chain.
87         By all rights this should crash when passed a string and accessing a property that does not exist, because
88         the string is a cell, getOwnPropertySlot should return false, and the cast to JSObject should be unsafe.
89         To work around this, JSString::getOwnPropertySlot actually implements 'get' functionality - searching the
90         prototype chain, and faking out a return value of undefined if no property is found.
91
92         This is a huge hazard, since fixing JSString::getOwnPropertySlot or calling getOwnPropertySlot on cells
93         from elsewhere would introduce bugs. Fortunately it is only ever called in this one place.
94
95         The fix here is to move getOwnPropertySlot onto JSObjecte and end this madness - cells don't have property
96         slots anyway.
97
98         Interesting changes are in JSCJSValueInlines.h, JSString.cpp - the rest is pretty much all JSCell -> JSObject.
99
100 2013-07-31  Michael Saboff  <msaboff@apple.com>
101
102         [Win] JavaScript crash.
103         https://bugs.webkit.org/show_bug.cgi?id=119339
104
105         Reviewed by Mark Hahnenberg.
106
107         * jit/JITStubsX86.h: Implement ctiVMThrowTrampoline and
108         ctiVMThrowTrampolineSlowpath the same way as the gcc x86 version does.
109
110 2013-07-30  Mark Hahnenberg  <mhahnenberg@apple.com>
111
112         GetByVal on Arguments does the wrong size load when checking the Arguments object length
113         https://bugs.webkit.org/show_bug.cgi?id=119281
114
115         Reviewed by Geoffrey Garen.
116
117         This leads to out of bounds accesses and subsequent crashes.
118
119         * dfg/DFGSpeculativeJIT.cpp:
120         (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
121         * dfg/DFGSpeculativeJIT64.cpp:
122         (JSC::DFG::SpeculativeJIT::compile):
123
124 2013-07-30  Oliver Hunt  <oliver@apple.com>
125
126         Add an assertion to SpeculateCellOperand
127         https://bugs.webkit.org/show_bug.cgi?id=119276
128
129         Reviewed by Michael Saboff.
130
131         More assertions are better
132
133         * dfg/DFGSpeculativeJIT64.cpp:
134         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
135         (JSC::DFG::SpeculativeJIT::compile):
136
137 2013-07-30  Mark Lam  <mark.lam@apple.com>
138
139         Fix problems with divot and lineStart mismatches.
140         https://bugs.webkit.org/show_bug.cgi?id=118662.
141
142         Reviewed by Oliver Hunt.
143
144         r152494 added the recording of lineStart values for divot positions.
145         This is needed for the computation of column numbers. Similarly, it also
146         added the recording of line numbers for the divot positions. One problem
147         with the approach taken was that the line and lineStart values were
148         recorded independently, and hence were not always guaranteed to be
149         sampled at the same place that the divot position is recorded. This
150         resulted in potential mismatches that cause some assertions to fail.
151
152         The solution is to introduce a JSTextPosition abstraction that records
153         the divot position, line, and lineStart as a single quantity. Wherever
154         we record the divot position as an unsigned int previously, we now record
155         its JSTextPosition which captures all 3 values in one go. This ensures
156         that the captured line and lineStart will always match the captured divot
157         position.
158
159         * bytecompiler/BytecodeGenerator.cpp:
160         (JSC::BytecodeGenerator::emitCall):
161         (JSC::BytecodeGenerator::emitCallEval):
162         (JSC::BytecodeGenerator::emitCallVarargs):
163         (JSC::BytecodeGenerator::emitConstruct):
164         (JSC::BytecodeGenerator::emitDebugHook):
165         - Use JSTextPosition instead of passing line and lineStart explicitly.
166         * bytecompiler/BytecodeGenerator.h:
167         (JSC::BytecodeGenerator::emitExpressionInfo):
168         - Use JSTextPosition instead of passing line and lineStart explicitly.
169         * bytecompiler/NodesCodegen.cpp:
170         (JSC::ThrowableExpressionData::emitThrowReferenceError):
171         (JSC::ResolveNode::emitBytecode):
172         (JSC::BracketAccessorNode::emitBytecode):
173         (JSC::DotAccessorNode::emitBytecode):
174         (JSC::NewExprNode::emitBytecode):
175         (JSC::EvalFunctionCallNode::emitBytecode):
176         (JSC::FunctionCallValueNode::emitBytecode):
177         (JSC::FunctionCallResolveNode::emitBytecode):
178         (JSC::FunctionCallBracketNode::emitBytecode):
179         (JSC::FunctionCallDotNode::emitBytecode):
180         (JSC::CallFunctionCallDotNode::emitBytecode):
181         (JSC::ApplyFunctionCallDotNode::emitBytecode):
182         (JSC::PostfixNode::emitResolve):
183         (JSC::PostfixNode::emitBracket):
184         (JSC::PostfixNode::emitDot):
185         (JSC::DeleteResolveNode::emitBytecode):
186         (JSC::DeleteBracketNode::emitBytecode):
187         (JSC::DeleteDotNode::emitBytecode):
188         (JSC::PrefixNode::emitResolve):
189         (JSC::PrefixNode::emitBracket):
190         (JSC::PrefixNode::emitDot):
191         (JSC::UnaryOpNode::emitBytecode):
192         (JSC::BinaryOpNode::emitStrcat):
193         (JSC::BinaryOpNode::emitBytecode):
194         (JSC::ThrowableBinaryOpNode::emitBytecode):
195         (JSC::InstanceOfNode::emitBytecode):
196         (JSC::emitReadModifyAssignment):
197         (JSC::ReadModifyResolveNode::emitBytecode):
198         (JSC::AssignResolveNode::emitBytecode):
199         (JSC::AssignDotNode::emitBytecode):
200         (JSC::ReadModifyDotNode::emitBytecode):
201         (JSC::AssignBracketNode::emitBytecode):
202         (JSC::ReadModifyBracketNode::emitBytecode):
203         (JSC::ForInNode::emitBytecode):
204         (JSC::WithNode::emitBytecode):
205         (JSC::ThrowNode::emitBytecode):
206         - Use JSTextPosition instead of passing line and lineStart explicitly.
207         * parser/ASTBuilder.h:
208         - Replaced ASTBuilder::PositionInfo with JSTextPosition.
209         (JSC::ASTBuilder::BinaryOpInfo::BinaryOpInfo):
210         (JSC::ASTBuilder::AssignmentInfo::AssignmentInfo):
211         (JSC::ASTBuilder::createResolve):
212         (JSC::ASTBuilder::createBracketAccess):
213         (JSC::ASTBuilder::createDotAccess):
214         (JSC::ASTBuilder::createRegExp):
215         (JSC::ASTBuilder::createNewExpr):
216         (JSC::ASTBuilder::createAssignResolve):
217         (JSC::ASTBuilder::createExprStatement):
218         (JSC::ASTBuilder::createForInLoop):
219         (JSC::ASTBuilder::createReturnStatement):
220         (JSC::ASTBuilder::createBreakStatement):
221         (JSC::ASTBuilder::createContinueStatement):
222         (JSC::ASTBuilder::createLabelStatement):
223         (JSC::ASTBuilder::createWithStatement):
224         (JSC::ASTBuilder::createThrowStatement):
225         (JSC::ASTBuilder::appendBinaryExpressionInfo):
226         (JSC::ASTBuilder::appendUnaryToken):
227         (JSC::ASTBuilder::unaryTokenStackLastStart):
228         (JSC::ASTBuilder::assignmentStackAppend):
229         (JSC::ASTBuilder::createAssignment):
230         (JSC::ASTBuilder::setExceptionLocation):
231         (JSC::ASTBuilder::makeDeleteNode):
232         (JSC::ASTBuilder::makeFunctionCallNode):
233         (JSC::ASTBuilder::makeBinaryNode):
234         (JSC::ASTBuilder::makeAssignNode):
235         (JSC::ASTBuilder::makePrefixNode):
236         (JSC::ASTBuilder::makePostfixNode):
237         - Use JSTextPosition instead of passing line and lineStart explicitly.
238         * parser/Lexer.cpp:
239         (JSC::::lex):
240         - Added support for capturing the appropriate JSTextPositions instead
241           of just the character offset.
242         * parser/Lexer.h:
243         (JSC::Lexer::currentPosition):
244         (JSC::::lexExpectIdentifier):
245         - Added support for capturing the appropriate JSTextPositions instead
246           of just the character offset.
247         * parser/NodeConstructors.h:
248         (JSC::Node::Node):
249         (JSC::ResolveNode::ResolveNode):
250         (JSC::EvalFunctionCallNode::EvalFunctionCallNode):
251         (JSC::FunctionCallValueNode::FunctionCallValueNode):
252         (JSC::FunctionCallResolveNode::FunctionCallResolveNode):
253         (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
254         (JSC::FunctionCallDotNode::FunctionCallDotNode):
255         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
256         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
257         (JSC::PostfixNode::PostfixNode):
258         (JSC::DeleteResolveNode::DeleteResolveNode):
259         (JSC::DeleteBracketNode::DeleteBracketNode):
260         (JSC::DeleteDotNode::DeleteDotNode):
261         (JSC::PrefixNode::PrefixNode):
262         (JSC::ReadModifyResolveNode::ReadModifyResolveNode):
263         (JSC::ReadModifyBracketNode::ReadModifyBracketNode):
264         (JSC::AssignBracketNode::AssignBracketNode):
265         (JSC::AssignDotNode::AssignDotNode):
266         (JSC::ReadModifyDotNode::ReadModifyDotNode):
267         (JSC::AssignErrorNode::AssignErrorNode):
268         (JSC::WithNode::WithNode):
269         (JSC::ForInNode::ForInNode):
270         - Use JSTextPosition instead of passing line and lineStart explicitly.
271         * parser/Nodes.cpp:
272         (JSC::StatementNode::setLoc):
273         - Use JSTextPosition instead of passing line and lineStart explicitly.
274         * parser/Nodes.h:
275         (JSC::Node::lineNo):
276         (JSC::Node::startOffset):
277         (JSC::Node::lineStartOffset):
278         (JSC::Node::position):
279         (JSC::ThrowableExpressionData::ThrowableExpressionData):
280         (JSC::ThrowableExpressionData::setExceptionSourceCode):
281         (JSC::ThrowableExpressionData::divot):
282         (JSC::ThrowableExpressionData::divotStart):
283         (JSC::ThrowableExpressionData::divotEnd):
284         (JSC::ThrowableSubExpressionData::ThrowableSubExpressionData):
285         (JSC::ThrowableSubExpressionData::setSubexpressionInfo):
286         (JSC::ThrowableSubExpressionData::subexpressionDivot):
287         (JSC::ThrowableSubExpressionData::subexpressionStart):
288         (JSC::ThrowableSubExpressionData::subexpressionEnd):
289         (JSC::ThrowablePrefixedSubExpressionData::ThrowablePrefixedSubExpressionData):
290         (JSC::ThrowablePrefixedSubExpressionData::setSubexpressionInfo):
291         (JSC::ThrowablePrefixedSubExpressionData::subexpressionDivot):
292         (JSC::ThrowablePrefixedSubExpressionData::subexpressionStart):
293         (JSC::ThrowablePrefixedSubExpressionData::subexpressionEnd):
294         - Use JSTextPosition instead of passing line and lineStart explicitly.
295         * parser/Parser.cpp:
296         (JSC::::Parser):
297         (JSC::::parseInner):
298         - Use JSTextPosition instead of passing line and lineStart explicitly.
299         (JSC::::didFinishParsing):
300         - Remove setting of m_lastLine value. We always pass in the value from
301           m_lastLine anyway. So, this assignment is effectively a nop.
302         (JSC::::parseVarDeclaration):
303         (JSC::::parseVarDeclarationList):
304         (JSC::::parseForStatement):
305         (JSC::::parseBreakStatement):
306         (JSC::::parseContinueStatement):
307         (JSC::::parseReturnStatement):
308         (JSC::::parseThrowStatement):
309         (JSC::::parseWithStatement):
310         (JSC::::parseTryStatement):
311         (JSC::::parseBlockStatement):
312         (JSC::::parseFunctionDeclaration):
313         (JSC::LabelInfo::LabelInfo):
314         (JSC::::parseExpressionOrLabelStatement):
315         (JSC::::parseExpressionStatement):
316         (JSC::::parseAssignmentExpression):
317         (JSC::::parseBinaryExpression):
318         (JSC::::parseProperty):
319         (JSC::::parsePrimaryExpression):
320         (JSC::::parseMemberExpression):
321         (JSC::::parseUnaryExpression):
322         - Use JSTextPosition instead of passing line and lineStart explicitly.
323         * parser/Parser.h:
324         (JSC::Parser::next):
325         (JSC::Parser::nextExpectIdentifier):
326         (JSC::Parser::getToken):
327         (JSC::Parser::tokenStartPosition):
328         (JSC::Parser::tokenEndPosition):
329         (JSC::Parser::lastTokenEndPosition):
330         (JSC::::parse):
331         - Use JSTextPosition instead of passing line and lineStart explicitly.
332         * parser/ParserTokens.h:
333         (JSC::JSTextPosition::JSTextPosition):
334         (JSC::JSTextPosition::operator+):
335         (JSC::JSTextPosition::operator-):
336         (JSC::JSTextPosition::operator int):
337         - Added JSTextPosition.
338         * parser/SyntaxChecker.h:
339         (JSC::SyntaxChecker::makeFunctionCallNode):
340         (JSC::SyntaxChecker::makeAssignNode):
341         (JSC::SyntaxChecker::makePrefixNode):
342         (JSC::SyntaxChecker::makePostfixNode):
343         (JSC::SyntaxChecker::makeDeleteNode):
344         (JSC::SyntaxChecker::createResolve):
345         (JSC::SyntaxChecker::createBracketAccess):
346         (JSC::SyntaxChecker::createDotAccess):
347         (JSC::SyntaxChecker::createRegExp):
348         (JSC::SyntaxChecker::createNewExpr):
349         (JSC::SyntaxChecker::createAssignResolve):
350         (JSC::SyntaxChecker::createForInLoop):
351         (JSC::SyntaxChecker::createReturnStatement):
352         (JSC::SyntaxChecker::createBreakStatement):
353         (JSC::SyntaxChecker::createContinueStatement):
354         (JSC::SyntaxChecker::createWithStatement):
355         (JSC::SyntaxChecker::createLabelStatement):
356         (JSC::SyntaxChecker::createThrowStatement):
357         (JSC::SyntaxChecker::appendBinaryExpressionInfo):
358         (JSC::SyntaxChecker::operatorStackPop):
359         - Use JSTextPosition instead of passing line and lineStart explicitly.
360
361 2013-07-29  Carlos Garcia Campos  <cgarcia@igalia.com>
362
363         Unreviewed. Fix make distcheck.
364
365         * GNUmakefile.list.am: Add missing files to compilation.
366         * bytecode/CodeBlock.cpp: Add a ENABLE(FTL_JIT) #if block to
367         include FTL header files not included in the compilation.
368         * dfg/DFGDriver.cpp: Ditto.
369         * dfg/DFGPlan.cpp: Ditto.
370
371 2013-07-29  Chris Curtis  <chris_curtis@apple.com>
372
373         Eager stack trace for error objects.
374         https://bugs.webkit.org/show_bug.cgi?id=118918
375
376         Reviewed by Geoffrey Garen.
377         
378         Chrome and Firefox give error objects the stack property and we wanted to match
379         that functionality. This allows developers to see the stack without throwing an object.
380
381         * runtime/ErrorInstance.cpp:
382         (JSC::ErrorInstance::finishCreation):
383          For error objects that are not thrown as an exception, we pass the stackTrace in 
384          as a parameter. This allows the error object to have the stack property.
385         
386         * interpreter/Interpreter.cpp:
387         (JSC::stackTraceAsString):
388         Helper function used to eliminate duplicate code.
389
390         (JSC::Interpreter::addStackTraceIfNecessary):
391         When an error object is created by the user the vm->exceptionStack is not set.
392         If the user throws this error object later the stack that is in the error object 
393         may not be the correct stack for the throw, so when we set the vm->exception stack,
394         the stack property on the error object is set as well.
395         
396         * runtime/ErrorConstructor.cpp:
397         (JSC::constructWithErrorConstructor):
398         (JSC::callErrorConstructor):
399         * runtime/NativeErrorConstructor.cpp:
400         (JSC::constructWithNativeErrorConstructor):
401         (JSC::callNativeErrorConstructor):
402         These functions indicate that the user created an error object. For all error objects 
403         that the user explicitly creates, the topCallFrame is at a new frame created to 
404         handle the user's call. In this case though, the error object needs the caller's 
405         frame to create the stack trace correctly.
406         
407         * interpreter/Interpreter.h:
408         * runtime/ErrorInstance.h:
409         (JSC::ErrorInstance::create):
410
411 2013-07-29  Gavin Barraclough  <barraclough@apple.com>
412
413         Some cleanup in PropertySlot
414         https://bugs.webkit.org/show_bug.cgi?id=119189
415
416         Reviewed by Geoff Garen.
417
418         PropertySlot represents a property in one of four states - value, getter, custom, or custom-index.
419         The state is currently tracked redundantly by two mechanisms - the custom getter function (m_getValue)
420         is set to a special value to indicate the type (other than custom), and the type is also tracked by
421         an enum - but only if cacheable. Cacheability can typically be determined by the value of m_offset
422         (this is invalidOffset if not cacheable).
423
424             * Internally, always track the type of the property using an enum value, PropertyType.
425             * Use m_offset to indicate cacheable.
426             * Keep the external interface (CachedPropertyType) unchanged.
427             * Better pack data into the m_data union.
428
429         Performance neutral.
430
431         * dfg/DFGRepatch.cpp:
432         (JSC::DFG::tryCacheGetByID):
433         (JSC::DFG::tryBuildGetByIDList):
434             - cachedPropertyType() -> isCacheable*()
435         * jit/JITPropertyAccess.cpp:
436         (JSC::JIT::privateCompileGetByIdProto):
437         (JSC::JIT::privateCompileGetByIdSelfList):
438         (JSC::JIT::privateCompileGetByIdProtoList):
439         (JSC::JIT::privateCompileGetByIdChainList):
440         (JSC::JIT::privateCompileGetByIdChain):
441             - cachedPropertyType() -> isCacheable*()
442         * jit/JITPropertyAccess32_64.cpp:
443         (JSC::JIT::privateCompileGetByIdProto):
444         (JSC::JIT::privateCompileGetByIdSelfList):
445         (JSC::JIT::privateCompileGetByIdProtoList):
446         (JSC::JIT::privateCompileGetByIdChainList):
447         (JSC::JIT::privateCompileGetByIdChain):
448             - cachedPropertyType() -> isCacheable*()
449         * jit/JITStubs.cpp:
450         (JSC::tryCacheGetByID):
451             - cachedPropertyType() -> isCacheable*()
452         * llint/LLIntSlowPaths.cpp:
453         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
454             - cachedPropertyType() -> isCacheable*()
455         * runtime/PropertySlot.cpp:
456         (JSC::PropertySlot::functionGetter):
457             - refactoring described above.
458         * runtime/PropertySlot.h:
459         (JSC::PropertySlot::PropertySlot):
460         (JSC::PropertySlot::getValue):
461         (JSC::PropertySlot::isCacheable):
462         (JSC::PropertySlot::isCacheableValue):
463         (JSC::PropertySlot::isCacheableGetter):
464         (JSC::PropertySlot::isCacheableCustom):
465         (JSC::PropertySlot::cachedOffset):
466         (JSC::PropertySlot::customGetter):
467         (JSC::PropertySlot::setValue):
468         (JSC::PropertySlot::setCustom):
469         (JSC::PropertySlot::setCacheableCustom):
470         (JSC::PropertySlot::setCustomIndex):
471         (JSC::PropertySlot::setGetterSlot):
472         (JSC::PropertySlot::setCacheableGetterSlot):
473         (JSC::PropertySlot::setUndefined):
474         (JSC::PropertySlot::slotBase):
475         (JSC::PropertySlot::setBase):
476             - refactoring described above.
477
478 2013-07-28  Oliver Hunt  <oliver@apple.com>
479
480         REGRESSION: Crash when opening Facebook.com
481         https://bugs.webkit.org/show_bug.cgi?id=119155
482
483         Reviewed by Andreas Kling.
484
485         Scope nodes are always objects, so we should be using SpecObjectOther
486         rather than SpecCellOther.  Marking Scopes as CellOther leads to a
487         contradiction in the CFA, resulting in bogus codegen.
488
489         * dfg/DFGAbstractInterpreterInlines.h:
490         (JSC::DFG::::executeEffects):
491         * dfg/DFGPredictionPropagationPhase.cpp:
492         (JSC::DFG::PredictionPropagationPhase::propagate):
493
494 2013-07-26  Oliver Hunt  <oliver@apple.com>
495
496         REGRESSION(FTL?): Crashes in plugin tests
497         https://bugs.webkit.org/show_bug.cgi?id=119141
498
499         Reviewed by Michael Saboff.
500
501         Re-export getStackTrace
502
503         * interpreter/Interpreter.h:
504
505 2013-07-26  Filip Pizlo  <fpizlo@apple.com>
506
507         REGRESSION: Crash when opening a message on Gmail
508         https://bugs.webkit.org/show_bug.cgi?id=119105
509
510         Reviewed by Oliver Hunt and Mark Hahnenberg.
511         
512         - GetById patching in the DFG needs to be more disciplined about how it derives the
513           slow path.
514         
515         - Fix some dumping code thread safety issues.
516
517         * bytecode/CallLinkStatus.cpp:
518         (JSC::CallLinkStatus::dump):
519         * bytecode/CodeBlock.cpp:
520         (JSC::CodeBlock::dumpBytecode):
521         * dfg/DFGRepatch.cpp:
522         (JSC::DFG::getPolymorphicStructureList):
523         (JSC::DFG::tryBuildGetByIDList):
524
525 2013-07-26  Balazs Kilvady  <kilvadyb@homejinni.com>
526
527         [mips] Fix LLINT build for mips backend
528         https://bugs.webkit.org/show_bug.cgi?id=119152
529
530         Reviewed by Oliver Hunt.
531
532         * offlineasm/mips.rb:
533
534 2013-07-19  Mark Hahnenberg  <mhahnenberg@apple.com>
535
536         Setting a large numeric property on an object causes it to allocate a huge backing store
537         https://bugs.webkit.org/show_bug.cgi?id=118914
538
539         Reviewed by Geoffrey Garen.
540
541         There are two distinct actions that we're trying to optimize for:
542
543         new Array(100000);
544
545         and:
546
547         a = [];
548         a[100000] = 42;
549         
550         In the first case, the programmer has indicated that they expect this Array to be very big, 
551         so they should get a contiguous array up until some threshold, above which we perform density 
552         calculations to see if it is indeed dense enough to warrant being contiguous.
553         
554         In the second case, the programmer hasn't indicated anything about the size of the Array, so 
555         we should be more conservative and assume it should be sparse until we've proven otherwise.
556         
557         Currently both of those cases are handled by MIN_SPARSE_ARRAY_INDEX. We should distinguish 
558         between them for the purposes of not over-allocating large backing stores like we see on 
559         http://www.peekanalytics.com/burgerjoints/
560         
561         The way that we'll do this is to keep the MIN_SPARSE_ARRAY_INDEX for the first case, and 
562         introduce a new heuristic for the second case. If we are putting to an index above a certain 
563         threshold (say, 1000) and it is beyond the length of the array, then we will use a sparse 
564         map instead. So for example, in the second case above the empty array has a blank indexing 
565         type and a length of 0. We put-by-val to an index > 1000 and > a.length, so we'll use a sparse map.
566
567         This fix is ~800x speedup on the accompanying regression test :-o
568
569         * runtime/ArrayConventions.h:
570         (JSC::indexIsSufficientlyBeyondLengthForSparseMap):
571         * runtime/JSObject.cpp:
572         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
573         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
574         (JSC::JSObject::putByIndexBeyondVectorLength):
575         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
576
577 2013-07-26  Julien Brianceau  <jbrianceau@nds.com>
578
579         REGRESSION(FTL): Fix lots of crashes in sh4 baseline JIT.
580         https://bugs.webkit.org/show_bug.cgi?id=119148
581
582         Reviewed by Csaba Osztrogonác.
583
584         * jit/JSInterfaceJIT.h: "secondArgumentRegister" is wrong for sh4.
585         * llint/LowLevelInterpreter32_64.asm: "move t0, a0" is missing
586         in nativeCallTrampoline for sh4. Reuse MIPS implementation to avoid
587         code duplication.
588
589 2013-07-26  Julien Brianceau  <jbrianceau@nds.com>
590
591         REGRESSION(FTL): Crash in sh4 baseline JIT.
592         https://bugs.webkit.org/show_bug.cgi?id=119138
593
594         Reviewed by Csaba Osztrogonác.
595
596         This crash is due to incomplete report of r150146 and r148474.
597
598         * jit/JITStubsSH4.h:
599
600 2013-07-26  Zan Dobersek  <zdobersek@igalia.com>
601
602         Unreviewed.
603
604         * Target.pri: Adding missing DFG files to the Qt build.
605
606 2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>
607
608         GTK and Qt buildfix after the intrusive win buildfix r153360.
609
610         * GNUmakefile.list.am:
611         * Target.pri:
612
613 2013-07-25  Gyuyoung Kim  <gyuyoung.kim@samsung.com>
614
615         Unreviewed, fix build break after r153360.
616
617         * CMakeLists.txt: Add CommonSlowPathsExceptions.cpp.
618
619 2013-07-25  Roger Fong  <roger_fong@apple.com>
620
621         Unreviewed build fix, AppleWin port.
622
623         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
624         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
625         * JavaScriptCore.vcxproj/copy-files.cmd:
626
627 2013-07-25  Roger Fong  <roger_fong@apple.com>
628
629         Unreviewed. Followup to r153360.
630
631         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
632         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
633
634 2013-07-25  Michael Saboff  <msaboff@apple.com>
635
636         [Windows] Speculative build fix.
637
638         Moved interpreterThrowInCaller() out of LLintExceptions.cpp into new CommonSlowPathsExceptions.cpp
639         that is always compiled.  Made LLInt::returnToThrow() conditional on LLINT being enabled.
640
641         * JavaScriptCore.xcodeproj/project.pbxproj:
642         * llint/LLIntExceptions.cpp:
643         * llint/LLIntExceptions.h:
644         * llint/LLIntSlowPaths.cpp:
645         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
646         * runtime/CommonSlowPaths.cpp:
647         (JSC::SLOW_PATH_DECL):
648         * runtime/CommonSlowPathsExceptions.cpp: Added.
649         (JSC::CommonSlowPaths::interpreterThrowInCaller):
650         * runtime/CommonSlowPathsExceptions.h: Added.
651
652 2013-07-25  Brent Fulgham  <bfulgham@apple.com>
653
654         [Windows] Unreviewed build fix.
655
656         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add missing IntendedStructureChange.h,.cpp and
657         parser/SourceCode.h,.cpp.
658         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
659
660 2013-07-25  Anders Carlsson  <andersca@apple.com>
661
662         ASSERT(m_vm->apiLock().currentThreadIsHoldingLock()); fails for Safari on current ToT
663         https://bugs.webkit.org/show_bug.cgi?id=119108
664
665         Reviewed by Mark Hahnenberg.
666
667         Add a currentThreadIsHoldingAPILock() function to VM that checks if the current thread is the exclusive API thread.
668
669         * heap/CopiedSpace.cpp:
670         (JSC::CopiedSpace::tryAllocateSlowCase):
671         * heap/Heap.cpp:
672         (JSC::Heap::protect):
673         (JSC::Heap::unprotect):
674         (JSC::Heap::collect):
675         * heap/MarkedAllocator.cpp:
676         (JSC::MarkedAllocator::allocateSlowCase):
677         * runtime/JSGlobalObject.cpp:
678         (JSC::JSGlobalObject::init):
679         * runtime/VM.h:
680         (JSC::VM::currentThreadIsHoldingAPILock):
681
682 2013-07-25  Zan Dobersek  <zdobersek@igalia.com>
683
684         REGRESSION(FTL): Most layout tests crashes
685         https://bugs.webkit.org/show_bug.cgi?id=119089
686
687         Reviewed by Oliver Hunt.
688
689         * runtime/ExecutionHarness.h:
690         (JSC::prepareForExecution): Move prepareForExecutionImpl call into its own statement. This prevents the GCC-compiled
691         code to create the PassOwnPtr<JSC::JITCode> (intended as a parameter to the installOptimizedCode call) from the jitCode
692         RefPtr<JSC::JITCode> parameter before the latter was actually given a proper value through the prepareForExecutionImpl call.
693         Currently it's created beforehand and therefor holds a null pointer before it's anchored as the JIT code in
694         JSC::CodeBlock::setJITCode, which later indirectly causes assertions in JSC::CodeBlock::jitCompile.
695         (JSC::prepareFunctionForExecution): Ditto for prepareFunctionForExecutionImpl.
696
697 2013-07-25  Brent Fulgham  <bfulgham@apple.com>
698
699         [Windows] Unreviewed build fix.
700
701         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Add missing 'ftl'
702         include path.
703
704 2013-07-25  Brent Fulgham  <bfulgham@apple.com>
705
706         [Windows] Unreviewed build fix.
707
708         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Add some missing files:
709         runtime/VM.h,.cpp; Remove deleted JSGlobalData.h,.cpp.
710         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
711
712 2013-07-25  Oliver Hunt  <oliver@apple.com>
713
714         Make all jit & non-jit combos build cleanly
715         https://bugs.webkit.org/show_bug.cgi?id=119102
716
717         Reviewed by Anders Carlsson.
718
719         * bytecode/CodeBlock.cpp:
720         (JSC::CodeBlock::counterValueForOptimizeSoon):
721         * bytecode/CodeBlock.h:
722         (JSC::CodeBlock::optimizeAfterWarmUp):
723         (JSC::CodeBlock::numberOfDFGCompiles):
724
725 2013-07-25  Oliver Hunt  <oliver@apple.com>
726
727         32 bit portion of load validation logic
728         https://bugs.webkit.org/show_bug.cgi?id=118878
729
730         Reviewed by NOBODY (Build fix).
731
732         * dfg/DFGSpeculativeJIT32_64.cpp:
733         (JSC::DFG::SpeculativeJIT::compile):
734
735 2013-07-25  Oliver Hunt  <oliver@apple.com>
736
737         More 32bit build fixes
738
739         - Apparnetly some compilers don't track the fastcall directive everywhere we expect
740
741         * API/APICallbackFunction.h:
742         (JSC::APICallbackFunction::call):
743         * bytecode/CodeBlock.cpp:
744         * runtime/Structure.cpp:
745
746 2013-07-25  Yi Shen  <max.hong.shen@gmail.com>
747
748         Optimize the thread locks for API Shims
749         https://bugs.webkit.org/show_bug.cgi?id=118573
750
751         Reviewed by Geoffrey Garen.
752
753         Remove the thread lock from API Shims if the VM has an exclusive thread (e.g. the VM 
754         only used by WebCore's main thread).
755
756         * API/APIShims.h:
757         (JSC::APIEntryShim::APIEntryShim):
758         (JSC::APICallbackShim::APICallbackShim):
759         * runtime/JSLock.cpp:
760         (JSC::JSLockHolder::JSLockHolder):
761         (JSC::JSLockHolder::init):
762         (JSC::JSLockHolder::~JSLockHolder):
763         (JSC::JSLock::DropAllLocks::DropAllLocks):
764         (JSC::JSLock::DropAllLocks::~DropAllLocks):
765         * runtime/VM.cpp:
766         (JSC::VM::VM):
767         * runtime/VM.h:
768
769 2013-07-25  Christophe Dumez  <ch.dumez@sisa.samsung.com>
770
771         Unreviewed build fix after r153218.
772
773         Broke the EFL port build with gcc 4.7.
774
775         * interpreter/StackIterator.cpp:
776         (JSC::printif):
777
778 2013-07-25  Julien Brianceau  <jbrianceau@nds.com>
779
780         Build fix: add missing #include.
781         https://bugs.webkit.org/show_bug.cgi?id=119087
782
783         Reviewed by Allan Sandfeld Jensen.
784
785         * bytecode/ArrayProfile.cpp:
786
787 2013-07-25  Ryuan Choi  <ryuan.choi@samsung.com>
788
789         Unreviewed, build fix on the EFL port.
790
791         * CMakeLists.txt: Added JSCTestRunnerUtils.cpp.
792
793 2013-07-25  Julien Brianceau  <jbrianceau@nds.com>
794
795         [sh4] Add missing store8(TrustedImm32, void*) implementation in baseline JIT.
796         https://bugs.webkit.org/show_bug.cgi?id=119083
797
798         Reviewed by Allan Sandfeld Jensen.
799
800         * assembler/MacroAssemblerSH4.h:
801         (JSC::MacroAssemblerSH4::store8):
802
803 2013-07-25  Allan Sandfeld Jensen  <allan.jensen@digia.com>
804
805         [Qt] Fix test build after FTL upstream
806
807         Unreviewed build fix.
808
809         * Target.pri:
810
811 2013-07-25  Allan Sandfeld Jensen  <allan.jensen@digia.com>
812
813         [Qt] Build fix after FTL.
814
815         Un Reviewed build fix.
816
817         * Target.pri:
818         * interpreter/StackIterator.cpp:
819         (JSC::StackIterator::Frame::print):
820
821 2013-07-25  Gabor Rapcsanyi  <rgabor@webkit.org>
822
823         Unreviewed build fix after FTL upstream.
824
825         * dfg/DFGWorklist.cpp:
826         (JSC::DFG::Worklist::~Worklist):
827
828 2013-07-25  Ryuan Choi  <ryuan.choi@samsung.com>
829
830         Unreviewed, build fix on the EFL port.
831
832         * CMakeLists.txt:
833         Added SourceCode.cpp and removed BlackBerry file.
834         * jit/JITCode.h:
835         (JSC::JITCode::nextTierJIT):
836         Fixed to build break because of -Werror=return-type
837         * parser/Lexer.cpp: Includes JSFunctionInlines.h
838         * runtime/JSScope.h:
839         (JSC::makeType):
840         Fixed to build break because of -Werror=return-type
841
842 2013-07-25  Ádám Kallai  <kadam@inf.u-szeged.hu>
843
844         Unreviewed build fixing after FTL upstream.
845
846         * runtime/Executable.cpp:
847         (JSC::FunctionExecutable::produceCodeBlockFor):
848
849 2013-07-25  Julien Brianceau  <jbrianceau@nds.com>
850
851         Add missing implementation of bxxxnz in sh4 LLINT.
852         https://bugs.webkit.org/show_bug.cgi?id=119079
853
854         Reviewed by Allan Sandfeld Jensen.
855
856         * offlineasm/sh4.rb:
857
858 2013-07-25  Gabor Rapcsanyi  <rgabor@webkit.org>
859
860         Unreviewed, build fix on the Qt port.
861
862         * Target.pri: Add additional build files for the FTL.
863
864 2013-07-25  Ádám Kallai  <kadam@inf.u-szeged.hu>
865
866         Unreviewed buildfix after FTL upstream..
867
868         * interpreter/StackIterator.cpp:
869         (JSC::StackIterator::Frame::codeType):
870         (JSC::StackIterator::Frame::functionName):
871         (JSC::StackIterator::Frame::sourceURL):
872         (JSC::StackIterator::Frame::logicalFrame):
873
874 2013-07-25  Zan Dobersek  <zdobersek@igalia.com>
875
876         Unreviewed.
877
878         * heap/CopyVisitor.cpp: Include CopiedSpaceInlines header so the CopiedSpace::recycleEvacuatedBlock
879         method is not left undefined, causing build failures on (at least) the GTK port.
880
881 2013-07-25  Zan Dobersek  <zdobersek@igalia.com>
882
883         Unreviewed, further build fixing on the GTK port.
884
885         * GNUmakefile.list.am: Add CompilationResult source files to the build.
886
887 2013-07-25  Zan Dobersek  <zdobersek@igalia.com>
888
889         Unreviewed GTK build fixing.
890
891         * GNUmakefile.am: Make the shared libjsc library depend on any changes to the build target list.
892         * GNUmakefile.list.am: Add additional build targets for files that were introduced by the FTL branch merge.
893
894 2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>
895
896         Buildfix after this error:
897         error: 'pathName' may be used uninitialized in this function [-Werror=uninitialized]
898
899         * dfg/DFGPlan.cpp:
900         (JSC::DFG::Plan::compileInThread):
901
902 2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>
903
904         One more buildfix after FTL upstream.
905
906         Return a dummy value after RELEASE_ASSERT_NOT_REACHED() to make GCC happy.
907
908         * dfg/DFGLazyJSValue.cpp:
909         (JSC::DFG::LazyJSValue::getValue):
910         (JSC::DFG::LazyJSValue::strictEqual):
911
912 2013-07-25  Julien Brianceau  <jbrianceau@nds.com>
913
914         Fix "Unhandled opcode localAnnotation" build error in sh4 and mips LLINT.
915         https://bugs.webkit.org/show_bug.cgi?id=119076
916
917         Reviewed by Allan Sandfeld Jensen.
918
919         * offlineasm/mips.rb:
920         * offlineasm/sh4.rb:
921
922 2013-07-25  Zan Dobersek  <zdobersek@igalia.com>
923
924         Unreviewed GTK build fix.
925
926         * GNUmakefile.list.am: Adding JSCTestRunnerUtils files to the build.
927
928 2013-07-25  Zan Dobersek  <zdobersek@igalia.com>
929
930         Unreviewed. Further build fixing for the GTK port. Adding the forwarding header
931         for JSCTestRunnerUtils.h as required by the DumpRenderTree compilation.
932
933         * ForwardingHeaders/JavaScriptCore/JSCTestRunnerUtils.h: Added.
934
935 2013-07-25  Zan Dobersek  <zdobersek@igalia.com>
936
937         Unreviewed. Fixing the GTK build after the FTL merging by updating the build targets list.
938
939         * GNUmakefile.am:
940         * GNUmakefile.list.am:
941
942 2013-07-25  Ádám Kallai  <kadam@inf.u-szeged.hu>
943
944         Unreviewed buildfix after FTL upstream.
945
946         * runtime/JSScope.h:
947         (JSC::needsVarInjectionChecks):
948
949 2013-07-25  Csaba Osztrogonác  <ossy@webkit.org>
950
951         One more fix after FTL upstream.
952
953         * Target.pri:
954         * bytecode/CodeBlock.h:
955         * bytecode/GetByIdStatus.h:
956         (JSC::GetByIdStatus::GetByIdStatus):
957
958 2013-07-24  Csaba Osztrogonác  <ossy@webkit.org>
959
960         Unreviewed buildfix after FTL upstream.
961
962         Add ftl directory as include path.
963
964         * CMakeLists.txt:
965         * JavaScriptCore.pri:
966
967 2013-07-24  Csaba Osztrogonác  <ossy@webkit.org>
968
969         Unreviewed buildfix after FTL upstream for non C++11 builds.
970
971         * interpreter/CallFrame.h:
972         * interpreter/StackIteratorPrivate.h:
973         (JSC::StackIterator::end):
974
975 2013-07-24  Oliver Hunt  <oliver@apple.com>
976
977         Endeavour to fix CMakelist builds
978
979         * CMakeLists.txt:
980
981 2013-07-24  Filip Pizlo  <fpizlo@apple.com>
982
983         fourthTier: DFG IR dumps should be easier to read
984         https://bugs.webkit.org/show_bug.cgi?id=119050
985
986         Reviewed by Mark Hahnenberg.
987         
988         Added a DumpContext that includes support for printing an endnote
989         that describes all structures in full, while the main flow of the
990         dump just uses made-up names for the structures. This is helpful
991         since Structure::dump() may print a lot. The stuff it prints is
992         useful, but if it's all inline with the surrounding thing you're        
993         dumping (often, a node in the DFG), then you get a ridiculously
994         long print-out. All classes that dump structures (including
995         Structure itself) now have dumpInContext() methods that use
996         inContext() for dumping anything that might transitively print a
997         structure. If Structure::dumpInContext() is called with a NULL
998         context, it just uses dump() like before. Hence you don't have to
999         know anything about DumpContext unless you want to.
1000         
1001         inContext(*structure, context) dumps something like %B4:Array,
1002         and the endnote will have something like:
1003         
1004             %B4:Array    = 0x10e91a180:[Array, {Edge:100, Normal:101, Line:102, NumPx:103, LastPx:104}, ArrayWithContiguous, Proto:0x10e99ffe0]
1005         
1006         where B4 is the inferred name that StringHashDumpContext came up
1007         with.
1008         
1009         Also shortened a bunch of other dumps, removing information that
1010         isn't so important.
1011         
1012         * JavaScriptCore.xcodeproj/project.pbxproj:
1013         * bytecode/ArrayProfile.cpp:
1014         (JSC::dumpArrayModes):
1015         * bytecode/CodeBlockHash.cpp:
1016         (JSC):
1017         (JSC::CodeBlockHash::CodeBlockHash):
1018         (JSC::CodeBlockHash::dump):
1019         * bytecode/CodeOrigin.cpp:
1020         (JSC::CodeOrigin::dumpInContext):
1021         (JSC):
1022         (JSC::InlineCallFrame::dumpInContext):
1023         (JSC::InlineCallFrame::dump):
1024         * bytecode/CodeOrigin.h:
1025         (CodeOrigin):
1026         (InlineCallFrame):
1027         * bytecode/Operands.h:
1028         (JSC::OperandValueTraits::isEmptyForDump):
1029         (Operands):
1030         (JSC::Operands::dump):
1031         (JSC):
1032         * bytecode/OperandsInlines.h: Added.
1033         (JSC):
1034         (JSC::::dumpInContext):
1035         * bytecode/StructureSet.h:
1036         (JSC::StructureSet::dumpInContext):
1037         (JSC::StructureSet::dump):
1038         (StructureSet):
1039         * dfg/DFGAbstractValue.cpp:
1040         (JSC::DFG::AbstractValue::dump):
1041         (DFG):
1042         (JSC::DFG::AbstractValue::dumpInContext):
1043         * dfg/DFGAbstractValue.h:
1044         (JSC::DFG::AbstractValue::operator!):
1045         (AbstractValue):
1046         * dfg/DFGCFAPhase.cpp:
1047         (JSC::DFG::CFAPhase::performBlockCFA):
1048         * dfg/DFGCommon.cpp:
1049         * dfg/DFGCommon.h:
1050         (JSC::DFG::NodePointerTraits::isEmptyForDump):
1051         * dfg/DFGDisassembler.cpp:
1052         (JSC::DFG::Disassembler::createDumpList):
1053         * dfg/DFGDisassembler.h:
1054         (Disassembler):
1055         * dfg/DFGFlushFormat.h:
1056         (WTF::inContext):
1057         (WTF):
1058         * dfg/DFGFlushLivenessAnalysisPhase.cpp:
1059         * dfg/DFGGraph.cpp:
1060         (JSC::DFG::Graph::dumpCodeOrigin):
1061         (JSC::DFG::Graph::dump):
1062         (JSC::DFG::Graph::dumpBlockHeader):
1063         * dfg/DFGGraph.h:
1064         (Graph):
1065         * dfg/DFGLazyJSValue.cpp:
1066         (JSC::DFG::LazyJSValue::dumpInContext):
1067         (JSC::DFG::LazyJSValue::dump):
1068         (DFG):
1069         * dfg/DFGLazyJSValue.h:
1070         (LazyJSValue):
1071         * dfg/DFGNode.h:
1072         (JSC::DFG::nodeMapDump):
1073         (WTF::inContext):
1074         (WTF):
1075         * dfg/DFGOSRExitCompiler32_64.cpp:
1076         (JSC::DFG::OSRExitCompiler::compileExit):
1077         * dfg/DFGOSRExitCompiler64.cpp:
1078         (JSC::DFG::OSRExitCompiler::compileExit):
1079         * dfg/DFGStructureAbstractValue.h:
1080         (JSC::DFG::StructureAbstractValue::dumpInContext):
1081         (JSC::DFG::StructureAbstractValue::dump):
1082         (StructureAbstractValue):
1083         * ftl/FTLExitValue.cpp:
1084         (JSC::FTL::ExitValue::dumpInContext):
1085         (JSC::FTL::ExitValue::dump):
1086         (FTL):
1087         * ftl/FTLExitValue.h:
1088         (ExitValue):
1089         * ftl/FTLLowerDFGToLLVM.cpp:
1090         * ftl/FTLValueSource.cpp:
1091         (JSC::FTL::ValueSource::dumpInContext):
1092         (FTL):
1093         * ftl/FTLValueSource.h:
1094         (ValueSource):
1095         * runtime/DumpContext.cpp: Added.
1096         (JSC):
1097         (JSC::DumpContext::DumpContext):
1098         (JSC::DumpContext::~DumpContext):
1099         (JSC::DumpContext::isEmpty):
1100         (JSC::DumpContext::dump):
1101         * runtime/DumpContext.h: Added.
1102         (JSC):
1103         (DumpContext):
1104         * runtime/JSCJSValue.cpp:
1105         (JSC::JSValue::dump):
1106         (JSC):
1107         (JSC::JSValue::dumpInContext):
1108         * runtime/JSCJSValue.h:
1109         (JSC):
1110         (JSValue):
1111         * runtime/Structure.cpp:
1112         (JSC::Structure::dumpInContext):
1113         (JSC):
1114         (JSC::Structure::dumpBrief):
1115         (JSC::Structure::dumpContextHeader):
1116         * runtime/Structure.h:
1117         (JSC):
1118         (Structure):
1119
1120 2013-07-22  Filip Pizlo  <fpizlo@apple.com>
1121
1122         fourthTier: DFG should do a high-level LICM before going to FTL
1123         https://bugs.webkit.org/show_bug.cgi?id=118749
1124
1125         Reviewed by Oliver Hunt.
1126         
1127         Implements LICM hoisting for nodes that never write anything and never read
1128         things that are clobbered by the loop. There are some other preconditions for
1129         hoisting, see DFGLICMPhase.cpp.
1130
1131         Also did a few fixes:
1132         
1133         - ClobberSet::add was failing to switch Super entries to Direct entries in
1134           some cases.
1135         
1136         - DFGClobberize.cpp needed to #include "Operations.h".
1137         
1138         - DCEPhase needs to process the graph in reverse DFS order, when we're in SSA.
1139         
1140         - AbstractInterpreter can now execute a Node without knowing its indexInBlock.
1141           Knowing the indexInBlock is an optional optimization that all other clients
1142           of AI still opt into, but LICM doesn't.
1143         
1144         This makes the FTL a 2.19x speed-up on imaging-gaussian-blur.
1145
1146         * JavaScriptCore.xcodeproj/project.pbxproj:
1147         * dfg/DFGAbstractInterpreter.h:
1148         (AbstractInterpreter):
1149         * dfg/DFGAbstractInterpreterInlines.h:
1150         (JSC::DFG::::executeEffects):
1151         (JSC::DFG::::execute):
1152         (DFG):
1153         (JSC::DFG::::clobberWorld):
1154         (JSC::DFG::::clobberStructures):
1155         * dfg/DFGAtTailAbstractState.cpp: Added.
1156         (DFG):
1157         (JSC::DFG::AtTailAbstractState::AtTailAbstractState):
1158         (JSC::DFG::AtTailAbstractState::~AtTailAbstractState):
1159         (JSC::DFG::AtTailAbstractState::createValueForNode):
1160         (JSC::DFG::AtTailAbstractState::forNode):
1161         * dfg/DFGAtTailAbstractState.h: Added.
1162         (DFG):
1163         (AtTailAbstractState):
1164         (JSC::DFG::AtTailAbstractState::initializeTo):
1165         (JSC::DFG::AtTailAbstractState::forNode):
1166         (JSC::DFG::AtTailAbstractState::variables):
1167         (JSC::DFG::AtTailAbstractState::block):
1168         (JSC::DFG::AtTailAbstractState::isValid):
1169         (JSC::DFG::AtTailAbstractState::setDidClobber):
1170         (JSC::DFG::AtTailAbstractState::setIsValid):
1171         (JSC::DFG::AtTailAbstractState::setBranchDirection):
1172         (JSC::DFG::AtTailAbstractState::setFoundConstants):
1173         (JSC::DFG::AtTailAbstractState::haveStructures):
1174         (JSC::DFG::AtTailAbstractState::setHaveStructures):
1175         * dfg/DFGBasicBlock.h:
1176         (JSC::DFG::BasicBlock::insertBeforeLast):
1177         * dfg/DFGBasicBlockInlines.h:
1178         (DFG):
1179         * dfg/DFGClobberSet.cpp:
1180         (JSC::DFG::ClobberSet::add):
1181         (JSC::DFG::ClobberSet::addAll):
1182         * dfg/DFGClobberize.cpp:
1183         (JSC::DFG::doesWrites):
1184         * dfg/DFGClobberize.h:
1185         (DFG):
1186         * dfg/DFGDCEPhase.cpp:
1187         (JSC::DFG::DCEPhase::DCEPhase):
1188         (JSC::DFG::DCEPhase::run):
1189         (JSC::DFG::DCEPhase::fixupBlock):
1190         (DCEPhase):
1191         * dfg/DFGEdgeDominates.h: Added.
1192         (DFG):
1193         (EdgeDominates):
1194         (JSC::DFG::EdgeDominates::EdgeDominates):
1195         (JSC::DFG::EdgeDominates::operator()):
1196         (JSC::DFG::EdgeDominates::result):
1197         (JSC::DFG::edgesDominate):
1198         * dfg/DFGFixupPhase.cpp:
1199         (JSC::DFG::FixupPhase::fixupNode):
1200         (JSC::DFG::FixupPhase::checkArray):
1201         * dfg/DFGLICMPhase.cpp: Added.
1202         (LICMPhase):
1203         (JSC::DFG::LICMPhase::LICMPhase):
1204         (JSC::DFG::LICMPhase::run):
1205         (JSC::DFG::LICMPhase::attemptHoist):
1206         (DFG):
1207         (JSC::DFG::performLICM):
1208         * dfg/DFGLICMPhase.h: Added.
1209         (DFG):
1210         * dfg/DFGPlan.cpp:
1211         (JSC::DFG::Plan::compileInThreadImpl):
1212
1213 2013-07-21  Filip Pizlo  <fpizlo@apple.com>
1214
1215         fourthTier: DFG Nodes should be able to abstractly tell you what they read and what they write
1216         https://bugs.webkit.org/show_bug.cgi?id=118910
1217
1218         Reviewed by Sam Weinig.
1219         
1220         Add the notion of AbstractHeap to the DFG. This is analogous to the AbstractHeap in
1221         the FTL, except that the FTL's AbstractHeaps are used during LLVM lowering and are
1222         engineered to obey LLVM TBAA logic. The FTL's AbstractHeaps are also engineered to
1223         be inexpensive to use (they just give you a TBAA node) but expensive to create (you
1224         create them all up front). FTL AbstractHeaps also don't actually give you the
1225         ability to reason about aliasing; they are *just* a mechanism for lowering to TBAA.
1226         The DFG's AbstractHeaps are engineered to be both cheap to create and cheap to use.
1227         They also give you aliasing machinery. The DFG AbstractHeaps are represented
1228         internally by a int64_t. Many comparisons between them are just integer comaprisons.
1229         AbstractHeaps form a three-level hierarchy (World is the supertype of everything,
1230         Kind with a TOP payload is a direct subtype of World, and Kind with a non-TOP
1231         payload is the direct subtype of its corresponding TOP Kind).
1232         
1233         Add the notion of a ClobberSet. This is the set of AbstractHeaps that you had
1234         clobbered. It represents the set that results from unifying a bunch of
1235         AbstractHeaps, and is intended to quickly answer overlap questions: does the given
1236         AbstractHeap overlap any AbstractHeap in the ClobberSet? To this end, if you add an
1237         AbstractHeap to a set, it "directly" adds the heap itself, and "super" adds all of
1238         its ancestors. An AbstractHeap is said to overlap a set if any direct or super
1239         member is equal to it, or if any of its ancestors are equal to a direct member.
1240         
1241         Example #1:
1242         
1243             - I add Variables(5). I.e. Variables is the Kind and 5 is the payload. This
1244               is a subtype of Variables, which is a subtype of World.
1245             - You query Variables. I.e. Variables with a TOP payload, which is the
1246               supertype of Variables(X) for any X, and a subtype of World.
1247             
1248             The set will have Variables(5) as a direct member, and Variables and World as
1249             super members. The Variables query will immediately return true, because
1250             Variables is indeed a super member.
1251         
1252         Example #2:
1253         
1254             - I add Variables(5)
1255             - You query NamedProperties
1256             
1257             NamedProperties is not a member at all (neither direct or super). We next
1258             query World. World is a member, but it's a super member, so we return false.
1259         
1260         Example #3:
1261         
1262             - I add Variables
1263             - You query Variables(5)
1264             
1265             The set will have Variables as a direct member, and World as a super member.
1266             The Variables(5) query will not find Variables(5) in the set, but then it
1267             will query Variables. Variables is a direct member, so we return true.
1268         
1269         Example #4:
1270         
1271             - I add Variables
1272             - You query NamedProperties(5)
1273             
1274             Neither NamedProperties nor NamedProperties(5) are members. We next query
1275             World. World is a member, but it's a super member, so we return false.
1276         
1277         Overlap queries require that either the heap being queried is in the set (either
1278         direct or super), or that one of its ancestors is a direct member. Another way to
1279         think about how this works is that two heaps A and B are said to overlap if
1280         A.isSubtypeOf(B) or B.isSubtypeOf(A). This is sound since heaps form a
1281         single-inheritance heirarchy. Consider that we wanted to implement a set that holds
1282         heaps and answers the question, "is any member in the set an ancestor (i.e.
1283         supertype) of some other heap". We would have the set contain the heaps themselves,
1284         and we would satisfy the query "A.isSubtypeOfAny(set)" by walking the ancestor
1285         chain of A, and repeatedly querying its membership in the set. This is what the
1286         "direct" members of our set do. Now consider the other part, where we want to ask if
1287         any member of the set is a descendent of a heap, or "A.isSupertypeOfAny(set)". We
1288         would implement this by implementing set.add(B) as adding not just B but also all of
1289         B's ancestors; then we would answer A.isSupertypeOfAny(set) by just checking if A is
1290         in the set. With two such sets - one that answers isSubtypeOfAny() and another that
1291         answers isSupertypeOfAny() - we could answer the "do any of my heaps overlap your
1292         heap" question. ClobberSet does this, but combines the two sets into a single
1293         HashMap. The HashMap's value, "direct", means that the key is a member of both the
1294         supertype set and the subtype set; if it's false then it's only a member of one of
1295         them.
1296         
1297         Finally, this adds a functorized clobberize() method that adds the read and write
1298         clobbers of a DFG::Node to read and write functors. Common functors for adding to
1299         ClobberSets, querying overlap, and doing nothing are provided. Convenient wrappers
1300         are also provided. This allows you to say things like:
1301         
1302             ClobberSet set;
1303             addWrites(graph, node1, set);
1304             if (readsOverlap(graph, node2, set))
1305                 // We know that node1 may write to something that node2 may read from.
1306         
1307         Currently this facility is only used to improve graph dumping, but it will be
1308         instrumental in both LICM and GVN. In the future, I want to completely kill the
1309         NodeClobbersWorld and NodeMightClobber flags, and eradicate CSEPhase's hackish way
1310         of accomplishing almost exactly what AbstractHeap gives you.
1311
1312         * JavaScriptCore.xcodeproj/project.pbxproj:
1313         * dfg/DFGAbstractHeap.cpp: Added.
1314         (DFG):
1315         (JSC::DFG::AbstractHeap::Payload::dump):
1316         (JSC::DFG::AbstractHeap::dump):
1317         (WTF):
1318         (WTF::printInternal):
1319         * dfg/DFGAbstractHeap.h: Added.
1320         (DFG):
1321         (AbstractHeap):
1322         (Payload):
1323         (JSC::DFG::AbstractHeap::Payload::Payload):
1324         (JSC::DFG::AbstractHeap::Payload::top):
1325         (JSC::DFG::AbstractHeap::Payload::isTop):
1326         (JSC::DFG::AbstractHeap::Payload::value):
1327         (JSC::DFG::AbstractHeap::Payload::valueImpl):
1328         (JSC::DFG::AbstractHeap::Payload::operator==):
1329         (JSC::DFG::AbstractHeap::Payload::operator!=):
1330         (JSC::DFG::AbstractHeap::Payload::operator<):
1331         (JSC::DFG::AbstractHeap::Payload::isDisjoint):
1332         (JSC::DFG::AbstractHeap::Payload::overlaps):
1333         (JSC::DFG::AbstractHeap::AbstractHeap):
1334         (JSC::DFG::AbstractHeap::operator!):
1335         (JSC::DFG::AbstractHeap::kind):
1336         (JSC::DFG::AbstractHeap::payload):
1337         (JSC::DFG::AbstractHeap::isDisjoint):
1338         (JSC::DFG::AbstractHeap::overlaps):
1339         (JSC::DFG::AbstractHeap::supertype):
1340         (JSC::DFG::AbstractHeap::hash):
1341         (JSC::DFG::AbstractHeap::operator==):
1342         (JSC::DFG::AbstractHeap::operator!=):
1343         (JSC::DFG::AbstractHeap::operator<):
1344         (JSC::DFG::AbstractHeap::isHashTableDeletedValue):
1345         (JSC::DFG::AbstractHeap::payloadImpl):
1346         (JSC::DFG::AbstractHeap::encode):
1347         (JSC::DFG::AbstractHeapHash::hash):
1348         (JSC::DFG::AbstractHeapHash::equal):
1349         (AbstractHeapHash):
1350         (WTF):
1351         * dfg/DFGClobberSet.cpp: Added.
1352         (DFG):
1353         (JSC::DFG::ClobberSet::ClobberSet):
1354         (JSC::DFG::ClobberSet::~ClobberSet):
1355         (JSC::DFG::ClobberSet::add):
1356         (JSC::DFG::ClobberSet::addAll):
1357         (JSC::DFG::ClobberSet::contains):
1358         (JSC::DFG::ClobberSet::overlaps):
1359         (JSC::DFG::ClobberSet::clear):
1360         (JSC::DFG::ClobberSet::direct):
1361         (JSC::DFG::ClobberSet::super):
1362         (JSC::DFG::ClobberSet::dump):
1363         (JSC::DFG::ClobberSet::setOf):
1364         (JSC::DFG::addReads):
1365         (JSC::DFG::addWrites):
1366         (JSC::DFG::addReadsAndWrites):
1367         (JSC::DFG::readsOverlap):
1368         (JSC::DFG::writesOverlap):
1369         * dfg/DFGClobberSet.h: Added.
1370         (DFG):
1371         (ClobberSet):
1372         (JSC::DFG::ClobberSet::isEmpty):
1373         (ClobberSetAdd):
1374         (JSC::DFG::ClobberSetAdd::ClobberSetAdd):
1375         (JSC::DFG::ClobberSetAdd::operator()):
1376         (ClobberSetOverlaps):
1377         (JSC::DFG::ClobberSetOverlaps::ClobberSetOverlaps):
1378         (JSC::DFG::ClobberSetOverlaps::operator()):
1379         (JSC::DFG::ClobberSetOverlaps::result):
1380         * dfg/DFGClobberize.cpp: Added.
1381         (DFG):
1382         (JSC::DFG::didWrites):
1383         * dfg/DFGClobberize.h: Added.
1384         (DFG):
1385         (JSC::DFG::clobberize):
1386         (NoOpClobberize):
1387         (JSC::DFG::NoOpClobberize::NoOpClobberize):
1388         (JSC::DFG::NoOpClobberize::operator()):
1389         (CheckClobberize):
1390         (JSC::DFG::CheckClobberize::CheckClobberize):
1391         (JSC::DFG::CheckClobberize::operator()):
1392         (JSC::DFG::CheckClobberize::result):
1393         * dfg/DFGGraph.cpp:
1394         (JSC::DFG::Graph::dump):
1395
1396 2013-07-21  Filip Pizlo  <fpizlo@apple.com>
1397
1398         fourthTier: It should be easy to figure out which blocks nodes belong to
1399         https://bugs.webkit.org/show_bug.cgi?id=118957
1400
1401         Reviewed by Sam Weinig.
1402
1403         * dfg/DFGGraph.cpp:
1404         (DFG):
1405         (JSC::DFG::Graph::initializeNodeOwners):
1406         * dfg/DFGGraph.h:
1407         (Graph):
1408         * dfg/DFGNode.h:
1409
1410 2013-07-21  Filip Pizlo  <fpizlo@apple.com>
1411
1412         fourthTier: NodeExitsForward shouldn't be duplicated in NodeType
1413         https://bugs.webkit.org/show_bug.cgi?id=118956
1414
1415         Reviewed by Sam Weinig.
1416         
1417         We had two way of expressing that something exits forward: the NodeExitsForward
1418         flag and the word 'Forward' in the NodeType. That's kind of dumb. This patch
1419         makes it just be a flag.
1420
1421         * dfg/DFGAbstractInterpreterInlines.h:
1422         (JSC::DFG::::executeEffects):
1423         * dfg/DFGArgumentsSimplificationPhase.cpp:
1424         (JSC::DFG::ArgumentsSimplificationPhase::run):
1425         * dfg/DFGCSEPhase.cpp:
1426         (JSC::DFG::CSEPhase::int32ToDoubleCSE):
1427         (JSC::DFG::CSEPhase::checkStructureElimination):
1428         (JSC::DFG::CSEPhase::structureTransitionWatchpointElimination):
1429         (JSC::DFG::CSEPhase::putStructureStoreElimination):
1430         (JSC::DFG::CSEPhase::checkArrayElimination):
1431         (JSC::DFG::CSEPhase::performNodeCSE):
1432         * dfg/DFGConstantFoldingPhase.cpp:
1433         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1434         * dfg/DFGFixupPhase.cpp:
1435         (JSC::DFG::FixupPhase::fixupNode):
1436         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
1437         * dfg/DFGMinifiedNode.h:
1438         (JSC::DFG::belongsInMinifiedGraph):
1439         (JSC::DFG::MinifiedNode::hasChild):
1440         * dfg/DFGNode.h:
1441         (JSC::DFG::Node::convertToStructureTransitionWatchpoint):
1442         (JSC::DFG::Node::hasStructureSet):
1443         (JSC::DFG::Node::hasStructure):
1444         (JSC::DFG::Node::hasArrayMode):
1445         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1446         * dfg/DFGNodeType.h:
1447         (DFG):
1448         (JSC::DFG::needsOSRForwardRewiring):
1449         * dfg/DFGPredictionPropagationPhase.cpp:
1450         (JSC::DFG::PredictionPropagationPhase::propagate):
1451         * dfg/DFGSafeToExecute.h:
1452         (JSC::DFG::safeToExecute):
1453         * dfg/DFGSpeculativeJIT.cpp:
1454         (JSC::DFG::SpeculativeJIT::compileInt32ToDouble):
1455         * dfg/DFGSpeculativeJIT32_64.cpp:
1456         (JSC::DFG::SpeculativeJIT::compile):
1457         * dfg/DFGSpeculativeJIT64.cpp:
1458         (JSC::DFG::SpeculativeJIT::compile):
1459         * dfg/DFGTypeCheckHoistingPhase.cpp:
1460         (JSC::DFG::TypeCheckHoistingPhase::run):
1461         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1462         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1463         * dfg/DFGVariableEventStream.cpp:
1464         (JSC::DFG::VariableEventStream::reconstruct):
1465         * ftl/FTLCapabilities.cpp:
1466         (JSC::FTL::canCompile):
1467         * ftl/FTLLowerDFGToLLVM.cpp:
1468         (JSC::FTL::LowerDFGToLLVM::compileNode):
1469         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
1470
1471 2013-07-21  Filip Pizlo  <fpizlo@apple.com>
1472
1473         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
1474         https://bugs.webkit.org/show_bug.cgi?id=118946
1475
1476         Reviewed by Geoffrey Garen.
1477         
1478         We want to decouple the exit target code origin of a node from the code origin
1479         for all other purposes. The purposes of code origins are:
1480         
1481         - Where the node will exit, if it exits. The exit target should be consistent with
1482           the surrounding nodes, in that if you just looked at the code origins of nodes in
1483           the graph, they would be consistent with the code origins in bytecode. This is
1484           necessary for live-at-bytecode analyses to work, and to preserve the original
1485           bytecode semantics when exiting.
1486         
1487         - What kind of code the node came from, for semantics thingies. For example, we
1488           might use the code origin to find the node's global object for doing an original
1489           array check. Or we might use it to determine if the code is in strict mode. Or
1490           other similar things. When we use the code origin in this way, we're basically
1491           using it as a way of describing the node's meta-data without putting it into the
1492           node directly, to save space. In the absurd extreme you could imagine nodes not
1493           even having NodeTypes or NodeFlags, and just using the CodeOrigin to determine
1494           what bytecode the node originated from. We won't do that, but you can think of
1495           this use of code origins as just a way of compressing meta-data.
1496         
1497         - What code origin we should supply profiling to, if we exit. This is closely
1498           related to the semantics thingies, in that the exit profiling is a persistent
1499           kind of semantic meta-data that survives between recompiles, and the only way to
1500           do that is to ascribe it to the original bytecode via the code origin.
1501         
1502         If we hoist a node, we need to change the exit target code origin, but we must not
1503         change the code origin for other purposes. The best way to do this is to decouple
1504         the two kinds of code origin.
1505         
1506         OSR exit data structures already do this, because they may edit the exit target
1507         code origin while keeping the code origin for profiling intact. This happens for
1508         forward exits. So, we just need to thread separation all the way back to DFG::Node.
1509         That's what this patch does.
1510
1511         * dfg/DFGNode.h:
1512         (JSC::DFG::Node::Node):
1513         (Node):
1514         * dfg/DFGOSRExit.cpp:
1515         (JSC::DFG::OSRExit::OSRExit):
1516         * dfg/DFGOSRExitBase.h:
1517         (JSC::DFG::OSRExitBase::OSRExitBase):
1518         * dfg/DFGSpeculativeJIT.cpp:
1519         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1520         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
1521         * dfg/DFGSpeculativeJIT.h:
1522         (SpeculativeJIT):
1523         * ftl/FTLLowerDFGToLLVM.cpp:
1524         (JSC::FTL::LowerDFGToLLVM::compileNode):
1525         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1526         (LowerDFGToLLVM):
1527         * ftl/FTLOSRExit.cpp:
1528         (JSC::FTL::OSRExit::OSRExit):
1529         * ftl/FTLOSRExit.h:
1530         (OSRExit):
1531
1532 2013-07-20  Filip Pizlo  <fpizlo@apple.com>
1533
1534         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
1535         https://bugs.webkit.org/show_bug.cgi?id=118866
1536
1537         Reviewed by Sam Weinig.
1538         
1539         Adds a safeToExecute() method that takes a node and an abstract state and tells you
1540         if the node will run without crashing under that state.
1541
1542         * JavaScriptCore.xcodeproj/project.pbxproj:
1543         * bytecode/CodeBlock.cpp:
1544         (JSC::CodeBlock::CodeBlock):
1545         * dfg/DFGCFAPhase.cpp:
1546         (CFAPhase):
1547         (JSC::DFG::CFAPhase::CFAPhase):
1548         (JSC::DFG::CFAPhase::run):
1549         (JSC::DFG::CFAPhase::performBlockCFA):
1550         (JSC::DFG::CFAPhase::performForwardCFA):
1551         * dfg/DFGSafeToExecute.h: Added.
1552         (DFG):
1553         (SafeToExecuteEdge):
1554         (JSC::DFG::SafeToExecuteEdge::SafeToExecuteEdge):
1555         (JSC::DFG::SafeToExecuteEdge::operator()):
1556         (JSC::DFG::SafeToExecuteEdge::result):
1557         (JSC::DFG::safeToExecute):
1558         * dfg/DFGStructureAbstractValue.h:
1559         (JSC::DFG::StructureAbstractValue::isValidOffset):
1560         (StructureAbstractValue):
1561         * runtime/Options.h:
1562         (JSC):
1563
1564 2013-07-20  Filip Pizlo  <fpizlo@apple.com>
1565
1566         fourthTier: FTL should be able to generate LLVM IR that uses an intrinsic for OSR exit
1567         https://bugs.webkit.org/show_bug.cgi?id=118948
1568
1569         Reviewed by Sam Weinig.
1570         
1571         - Add the ability to generate LLVM IR but then not use it, via --llvmAlwaysFails=true.
1572           This allows doing "what if" experiments with IR generation, even if the generated IR
1573           can't yet execute.
1574         
1575         - Add an OSR exit path that just calls an intrinsic that combines the branch and the
1576           off-ramp.
1577
1578         * JavaScriptCore.xcodeproj/project.pbxproj:
1579         * dfg/DFGPlan.cpp:
1580         (JSC::DFG::Plan::compileInThreadImpl):
1581         * ftl/FTLFail.cpp: Added.
1582         (FTL):
1583         (JSC::FTL::fail):
1584         * ftl/FTLFail.h: Added.
1585         (FTL):
1586         * ftl/FTLIntrinsicRepository.h:
1587         (FTL):
1588         * ftl/FTLLowerDFGToLLVM.cpp:
1589         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1590         (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
1591         * runtime/Options.h:
1592         (JSC):
1593
1594 2013-07-19  Filip Pizlo  <fpizlo@apple.com>
1595
1596         fourthTier: StringObjectUse uses structures, and CSE should know that
1597         https://bugs.webkit.org/show_bug.cgi?id=118940
1598
1599         Reviewed by Geoffrey Garen.
1600         
1601         This is asymptomatic right now, but we should fix it.
1602
1603         * JavaScriptCore.xcodeproj/project.pbxproj:
1604         * dfg/DFGCSEPhase.cpp:
1605         (JSC::DFG::CSEPhase::putStructureStoreElimination):
1606         * dfg/DFGEdgeUsesStructure.h: Added.
1607         (DFG):
1608         (EdgeUsesStructure):
1609         (JSC::DFG::EdgeUsesStructure::EdgeUsesStructure):
1610         (JSC::DFG::EdgeUsesStructure::operator()):
1611         (JSC::DFG::EdgeUsesStructure::result):
1612         (JSC::DFG::edgesUseStructure):
1613         * dfg/DFGUseKind.h:
1614         (DFG):
1615         (JSC::DFG::usesStructure):
1616
1617 2013-07-19  Filip Pizlo  <fpizlo@apple.com>
1618
1619         fourthTier: String GetByVal out-of-bounds handling is so wrong
1620         https://bugs.webkit.org/show_bug.cgi?id=118935
1621
1622         Reviewed by Geoffrey Garen.
1623         
1624         Bunch of String GetByVal out-of-bounds fixes:
1625         
1626         - Even if the string proto chain is sane, we need to watch out for negative
1627           indices. They may get values or call getters in the prototypes, since proto
1628           sanity doesn't check for negative indexed properties, as they are not
1629           technically indexed properties.
1630         
1631         - GetByVal String out-of-bounds does in fact clobberWorld(). CSE should be
1632           given this information.
1633         
1634         - GetByVal String out-of-bounds does in fact clobberWorld(). CFA should be
1635           given this information.
1636         
1637         Also fixed some other things:
1638         
1639         - If the DFG is disabled, the testRunner should pretend that we've done a
1640           bunch of DFG compiles. That's necessary to prevent the tests from timing
1641           out.
1642         
1643         - Disassembler shouldn't try to dump source code since it's not safe in the
1644           concurrent JIT.
1645
1646         * API/JSCTestRunnerUtils.cpp:
1647         (JSC::numberOfDFGCompiles):
1648         * JavaScriptCore.xcodeproj/project.pbxproj:
1649         * dfg/DFGAbstractInterpreterInlines.h:
1650         (JSC::DFG::::executeEffects):
1651         * dfg/DFGDisassembler.cpp:
1652         (JSC::DFG::Disassembler::dumpHeader):
1653         * dfg/DFGGraph.h:
1654         (JSC::DFG::Graph::byValIsPure):
1655         * dfg/DFGSaneStringGetByValSlowPathGenerator.h: Added.
1656         (DFG):
1657         (SaneStringGetByValSlowPathGenerator):
1658         (JSC::DFG::SaneStringGetByValSlowPathGenerator::SaneStringGetByValSlowPathGenerator):
1659         (JSC::DFG::SaneStringGetByValSlowPathGenerator::generateInternal):
1660         * dfg/DFGSpeculativeJIT.cpp:
1661         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
1662
1663 2013-07-19  Filip Pizlo  <fpizlo@apple.com>
1664
1665         fourthTier: Structure::isValidOffset() should be able to tell you if you're loading a valid JSValue, and not just not crashing
1666         https://bugs.webkit.org/show_bug.cgi?id=118911
1667
1668         Reviewed by Geoffrey Garen.
1669         
1670         We could also have a separate method like "willNotCrash(offset)", but that's not
1671         what isValidOffset() is intended to mean.
1672
1673         * runtime/Structure.h:
1674         (JSC::Structure::isValidOffset):
1675
1676 2013-07-19  Filip Pizlo  <fpizlo@apple.com>
1677
1678         fourthTier: Structure should be able to tell you if it's valid to load at a given offset from any object with that structure
1679         https://bugs.webkit.org/show_bug.cgi?id=118878
1680
1681         Reviewed by Oliver Hunt.
1682         
1683         - Change Structure::isValidOffset() to actually answer the question "If I attempted
1684           to load from an object of this structure, at this offset, would I commit suicide
1685           or would I get back some kind of value?"
1686         
1687         - Change StorageAccessData::offset to use a PropertyOffset. It should have been that
1688           way from the start.
1689         
1690         - Fix PutStructure so that it sets haveStructures in all of the cases that it should.
1691         
1692         - Make GetByOffset also reference the base object in addition to the butterfly.
1693         
1694         The future use of this power will be to answer questions like "If I hoisted this
1695         GetByOffset or PutByOffset to this point, would it cause crashes, or would it be
1696         fine?"
1697         
1698         I don't currently plan to use this power to perform validation, since the CSE has
1699         the power to eliminate CheckStructure's that the CFA wouldn't be smart enough to
1700         remove - both in the case of StructureSets where size >= 2 and in the case of
1701         CheckStructures that match across PutStructures. At first I tried to write a
1702         validator that was aware of this, but the validation code got way too complicated
1703         and I started having nightmares of spurious assertion bugs being filed against me.
1704         
1705         This also changes some of the code for how we hash FunctionExecutable's for debug
1706         dumps, since that code still had some thread-safety issues. Basically, the
1707         concurrent JIT needs to use the CodeBlock's precomputed hash and never call anything
1708         that could transitively try to compute the hash from the source code. The source
1709         code is a string that may be lazily computed, and that involves all manner of thread
1710         unsafe things.
1711
1712         * bytecode/CodeOrigin.cpp:
1713         (JSC::InlineCallFrame::hash):
1714         * dfg/DFGAbstractInterpreterInlines.h:
1715         (JSC::DFG::::executeEffects):
1716         * dfg/DFGByteCodeParser.cpp:
1717         (JSC::DFG::ByteCodeParser::handleGetByOffset):
1718         (JSC::DFG::ByteCodeParser::handlePutByOffset):
1719         (JSC::DFG::ByteCodeParser::parseBlock):
1720         * dfg/DFGCFAPhase.cpp:
1721         (JSC::DFG::CFAPhase::performBlockCFA):
1722         * dfg/DFGConstantFoldingPhase.cpp:
1723         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1724         * dfg/DFGFixupPhase.cpp:
1725         (JSC::DFG::FixupPhase::fixupNode):
1726         * dfg/DFGGraph.h:
1727         (StorageAccessData):
1728         * dfg/DFGNode.h:
1729         (JSC::DFG::Node::convertToGetByOffset):
1730         * dfg/DFGSpeculativeJIT64.cpp:
1731         (JSC::DFG::SpeculativeJIT::compile):
1732         * ftl/FTLLowerDFGToLLVM.cpp:
1733         (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
1734         (JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
1735         * runtime/FunctionExecutableDump.cpp:
1736         (JSC::FunctionExecutableDump::dump):
1737         * runtime/Structure.h:
1738         (Structure):
1739         (JSC::Structure::isValidOffset):
1740
1741 2013-07-18  Filip Pizlo  <fpizlo@apple.com>
1742
1743         fourthTier: AbstractInterpreter should explicitly ask AbstractState to create new AbstractValues for newly born nodes
1744         https://bugs.webkit.org/show_bug.cgi?id=118880
1745
1746         Reviewed by Sam Weinig.
1747         
1748         It should be possible to have an AbstractState that is backed by a HashMap. But to
1749         do this, the AbstractInterpreter should explicitly ask for new nodes to be added to
1750         the map, since otherwise the idiom of getting a reference to the AbstractValue
1751         returned by forNode() would cause really subtle memory corruption bugs.
1752
1753         * dfg/DFGAbstractInterpreterInlines.h:
1754         (JSC::DFG::::executeEffects):
1755         * dfg/DFGInPlaceAbstractState.h:
1756         (JSC::DFG::InPlaceAbstractState::createValueForNode):
1757         (InPlaceAbstractState):
1758
1759 2013-07-18  Filip Pizlo  <fpizlo@apple.com>
1760
1761         fourthTier: Decouple the way that CFA stores its state from the way it does abstract interpretation
1762         https://bugs.webkit.org/show_bug.cgi?id=118835
1763
1764         Reviewed by Oliver Hunt.
1765         
1766         This separates AbstractState into two things:
1767         
1768         - InPlaceAbstractState, which can tell you the abstract state of anything you
1769           might care about, and uses the old AbstractState's algorithms and data
1770           structures for doing so.
1771         
1772         - AbstractInterpreter<AbstractStateType>, which can execute a DFG::Node* with
1773           respect to an AbstractStateType. Currently we always use
1774           AbstractStateType = InPlaceAbstractState. But we could drop in an other
1775           class that supports basic primitives like forNode() and variables().
1776         
1777         This is important because:
1778         
1779         - We want to hoist things out of loops.
1780
1781         - We don't know what things rely on what type checks.
1782
1783         - We only want to hoist type checks out of loops if they aren't clobbered.
1784
1785         - We may want to still hoist things that depended on those type checks, if it's
1786           safe to do those things based on the CFA state at the tail of the loop
1787           pre-header.
1788
1789         - We don't want things to rely on their type checks by way of a token, because
1790           that's just weird.
1791
1792         So, we want to be able to have a special form of the CFA that can
1793         incrementally update a basic block's state-at-tail, and we want to be able to
1794         do this for multiple blocks simultaneously. This requires *not* storing the
1795         per-node state in the nodes themselves, but instead using the at-tail HashMap
1796         directly.
1797
1798         Hence we need to have a way of making the abstract interpreter (i.e.
1799         AbstractState::execute) polymorphic with respect to state representation. Put
1800         another way, we need to separate the way that abstract state is represented
1801         from the way DFG IR is abstractly interpreted.
1802
1803         * JavaScriptCore.xcodeproj/project.pbxproj:
1804         * dfg/DFGAbstractInterpreter.h: Added.
1805         (DFG):
1806         (AbstractInterpreter):
1807         (JSC::DFG::AbstractInterpreter::forNode):
1808         (JSC::DFG::AbstractInterpreter::variables):
1809         (JSC::DFG::AbstractInterpreter::needsTypeCheck):
1810         (JSC::DFG::AbstractInterpreter::filterEdgeByUse):
1811         (JSC::DFG::AbstractInterpreter::filter):
1812         (JSC::DFG::AbstractInterpreter::filterArrayModes):
1813         (JSC::DFG::AbstractInterpreter::filterByValue):
1814         (JSC::DFG::AbstractInterpreter::trySetConstant):
1815         (JSC::DFG::AbstractInterpreter::filterByType):
1816         * dfg/DFGAbstractInterpreterInlines.h: Added.
1817         (DFG):
1818         (JSC::DFG::::AbstractInterpreter):
1819         (JSC::DFG::::~AbstractInterpreter):
1820         (JSC::DFG::::booleanResult):
1821         (JSC::DFG::::startExecuting):
1822         (JSC::DFG::::executeEdges):
1823         (JSC::DFG::::verifyEdge):
1824         (JSC::DFG::::verifyEdges):
1825         (JSC::DFG::::executeEffects):
1826         (JSC::DFG::::execute):
1827         (JSC::DFG::::clobberWorld):
1828         (JSC::DFG::::clobberCapturedVars):
1829         (JSC::DFG::::clobberStructures):
1830         (JSC::DFG::::dump):
1831         (JSC::DFG::::filter):
1832         (JSC::DFG::::filterArrayModes):
1833         (JSC::DFG::::filterByValue):
1834         * dfg/DFGAbstractState.cpp: Removed.
1835         * dfg/DFGAbstractState.h: Removed.
1836         * dfg/DFGArgumentsSimplificationPhase.cpp:
1837         * dfg/DFGCFAPhase.cpp:
1838         (JSC::DFG::CFAPhase::CFAPhase):
1839         (JSC::DFG::CFAPhase::performBlockCFA):
1840         (CFAPhase):
1841         * dfg/DFGCFGSimplificationPhase.cpp:
1842         * dfg/DFGConstantFoldingPhase.cpp:
1843         (JSC::DFG::ConstantFoldingPhase::ConstantFoldingPhase):
1844         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1845         (ConstantFoldingPhase):
1846         * dfg/DFGInPlaceAbstractState.cpp: Added.
1847         (DFG):
1848         (JSC::DFG::InPlaceAbstractState::InPlaceAbstractState):
1849         (JSC::DFG::InPlaceAbstractState::~InPlaceAbstractState):
1850         (JSC::DFG::InPlaceAbstractState::beginBasicBlock):
1851         (JSC::DFG::setLiveValues):
1852         (JSC::DFG::InPlaceAbstractState::initialize):
1853         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
1854         (JSC::DFG::InPlaceAbstractState::reset):
1855         (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
1856         (JSC::DFG::InPlaceAbstractState::merge):
1857         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
1858         (JSC::DFG::InPlaceAbstractState::mergeVariableBetweenBlocks):
1859         * dfg/DFGInPlaceAbstractState.h: Added.
1860         (DFG):
1861         (InPlaceAbstractState):
1862         (JSC::DFG::InPlaceAbstractState::forNode):
1863         (JSC::DFG::InPlaceAbstractState::variables):
1864         (JSC::DFG::InPlaceAbstractState::block):
1865         (JSC::DFG::InPlaceAbstractState::didClobber):
1866         (JSC::DFG::InPlaceAbstractState::isValid):
1867         (JSC::DFG::InPlaceAbstractState::setDidClobber):
1868         (JSC::DFG::InPlaceAbstractState::setIsValid):
1869         (JSC::DFG::InPlaceAbstractState::setBranchDirection):
1870         (JSC::DFG::InPlaceAbstractState::setFoundConstants):
1871         (JSC::DFG::InPlaceAbstractState::haveStructures):
1872         (JSC::DFG::InPlaceAbstractState::setHaveStructures):
1873         * dfg/DFGMergeMode.h: Added.
1874         (DFG):
1875         * dfg/DFGSpeculativeJIT.cpp:
1876         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
1877         (JSC::DFG::SpeculativeJIT::backwardTypeCheck):
1878         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1879         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
1880         (JSC::DFG::SpeculativeJIT::speculateStringIdentAndLoadStorage):
1881         (JSC::DFG::SpeculativeJIT::speculateStringObject):
1882         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
1883         * dfg/DFGSpeculativeJIT.h:
1884         (JSC::DFG::SpeculativeJIT::needsTypeCheck):
1885         (SpeculativeJIT):
1886         * dfg/DFGSpeculativeJIT32_64.cpp:
1887         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
1888         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1889         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
1890         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
1891         * dfg/DFGSpeculativeJIT64.cpp:
1892         (JSC::DFG::SpeculativeJIT::fillSpeculateIntInternal):
1893         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1894         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
1895         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
1896         * ftl/FTLLowerDFGToLLVM.cpp:
1897         (FTL):
1898         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
1899         (JSC::FTL::LowerDFGToLLVM::compileNode):
1900         (JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
1901         (JSC::FTL::LowerDFGToLLVM::speculate):
1902         (JSC::FTL::LowerDFGToLLVM::speculateNumber):
1903         (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
1904         (LowerDFGToLLVM):
1905
1906 2013-07-18  Filip Pizlo  <fpizlo@apple.com>
1907
1908         fourthTier: DFG shouldn't create CheckStructures for array accesses except if the ArrayMode implies an original array access
1909         https://bugs.webkit.org/show_bug.cgi?id=118867
1910
1911         Reviewed by Mark Hahnenberg.
1912         
1913         This allows us to kill off a bunch of code in the parser, in fixup, and to simplify
1914         ArrayProfile.
1915
1916         It also makes it easier to ask any array-using node how to create its type check.
1917         
1918         Doing this required fixing a bug in LowLevelInterpreter64, where it was storing into
1919         an array profile, thinking that it was storing into a value profile. Reshuffling the
1920         fields in ArrayProfile revealed this.
1921
1922         * bytecode/ArrayProfile.cpp:
1923         (JSC::ArrayProfile::computeUpdatedPrediction):
1924         (JSC::ArrayProfile::briefDescriptionWithoutUpdating):
1925         * bytecode/ArrayProfile.h:
1926         (JSC::ArrayProfile::ArrayProfile):
1927         (ArrayProfile):
1928         * bytecode/CodeBlock.cpp:
1929         (JSC::CodeBlock::updateAllArrayPredictions):
1930         (JSC::CodeBlock::updateAllPredictions):
1931         * bytecode/CodeBlock.h:
1932         (CodeBlock):
1933         (JSC::CodeBlock::updateAllArrayPredictions):
1934         * dfg/DFGArrayMode.h:
1935         (ArrayMode):
1936         * dfg/DFGByteCodeParser.cpp:
1937         (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath):
1938         (JSC::DFG::ByteCodeParser::parseBlock):
1939         * dfg/DFGFixupPhase.cpp:
1940         (JSC::DFG::FixupPhase::fixupNode):
1941         (FixupPhase):
1942         (JSC::DFG::FixupPhase::checkArray):
1943         (JSC::DFG::FixupPhase::blessArrayOperation):
1944         * llint/LowLevelInterpreter64.asm:
1945
1946 2013-07-18  Filip Pizlo  <fpizlo@apple.com>
1947
1948         fourthTier: CFA should consider live-at-head for clobbering and dumping
1949         https://bugs.webkit.org/show_bug.cgi?id=118857
1950
1951         Reviewed by Mark Hahnenberg.
1952         
1953         - clobberStructures() was not considering nodes live-at-head when in SSA
1954           form. This means it would fail to clobber some structures.
1955         
1956         - dump() was not considering nodes live-at-head when in SSA form. This
1957           means it wouldn't dump everything that you might be interested in.
1958         
1959         - AbstractState::m_currentNode is a useless variable and we should get
1960           rid of it.
1961
1962         * dfg/DFGAbstractState.cpp:
1963         (JSC::DFG::AbstractState::AbstractState):
1964         (JSC::DFG::AbstractState::beginBasicBlock):
1965         (JSC::DFG::AbstractState::reset):
1966         (JSC::DFG::AbstractState::startExecuting):
1967         (JSC::DFG::AbstractState::clobberStructures):
1968         (JSC::DFG::AbstractState::dump):
1969         * dfg/DFGAbstractState.h:
1970         (AbstractState):
1971
1972 2013-07-16  Filip Pizlo  <fpizlo@apple.com>
1973
1974         fourthTier: Add a phase to create loop pre-headers
1975         https://bugs.webkit.org/show_bug.cgi?id=118778
1976
1977         Reviewed by Oliver Hunt.
1978         
1979         Add a loop pre-header creation phase. Any loop that doesn't already have
1980         just one predecessor that isn't part of the loop has a pre-header
1981         prepended. All non-loop predecessors then jump to that pre-header.
1982         
1983         Also fix a handful of bugs:
1984         
1985         - DFG::Analysis should set m_valid before running the analysis, since that
1986           makes it easier to use ASSERT(m_valid) in the analysis' methods, which
1987           may be called by the analysis before the analysis completes. NaturalLoops
1988           does this with loopsOf().
1989         
1990         - NaturalLoops::headerOf() was missing a check for innerMostLoopOf()
1991           returning 0, since that'll happen if the block isn't in any loop.
1992         
1993         - Change BlockInsertionSet to dethread the graph, since anyone using it
1994           will want to do so.
1995         
1996         - Change dethreading to ignore SSA form graphs.
1997         
1998         This also adds NaturalLoops::belongsTo(), which I always used in the
1999         pre-header creation phase. I didn't end up using it but I'll probably use
2000         it in the near future.
2001         
2002         * JavaScriptCore.xcodeproj/project.pbxproj:
2003         * dfg/DFGAnalysis.h:
2004         (JSC::DFG::Analysis::computeIfNecessary):
2005         * dfg/DFGBlockInsertionSet.cpp:
2006         (JSC::DFG::BlockInsertionSet::execute):
2007         * dfg/DFGCriticalEdgeBreakingPhase.cpp:
2008         (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
2009         * dfg/DFGGraph.cpp:
2010         (JSC::DFG::Graph::dethread):
2011         * dfg/DFGLoopPreHeaderCreationPhase.cpp: Added.
2012         (DFG):
2013         (LoopPreHeaderCreationPhase):
2014         (JSC::DFG::LoopPreHeaderCreationPhase::LoopPreHeaderCreationPhase):
2015         (JSC::DFG::LoopPreHeaderCreationPhase::run):
2016         (JSC::DFG::performLoopPreHeaderCreation):
2017         * dfg/DFGLoopPreHeaderCreationPhase.h: Added.
2018         (DFG):
2019         * dfg/DFGNaturalLoops.h:
2020         (NaturalLoop):
2021         (JSC::DFG::NaturalLoops::headerOf):
2022         (JSC::DFG::NaturalLoops::innerMostLoopOf):
2023         (JSC::DFG::NaturalLoops::innerMostOuterLoop):
2024         (JSC::DFG::NaturalLoops::belongsTo):
2025         (NaturalLoops):
2026         * dfg/DFGPlan.cpp:
2027         (JSC::DFG::Plan::compileInThreadImpl):
2028
2029 2013-07-16  Filip Pizlo  <fpizlo@apple.com>
2030
2031         fourthTier: Rationalize Node::replacement
2032         https://bugs.webkit.org/show_bug.cgi?id=118774
2033
2034         Reviewed by Oliver Hunt.
2035         
2036         - Clearing of replacements is now done in Graph::clearReplacements().
2037         
2038         - New nodes now have replacement set to 0.
2039         
2040         - Node::replacement is now part of a 'misc' union. I'll be putting at least
2041           one other field into that union as part of LICM work (see
2042           https://bugs.webkit.org/show_bug.cgi?id=118749).
2043
2044         * dfg/DFGCPSRethreadingPhase.cpp:
2045         (JSC::DFG::CPSRethreadingPhase::run):
2046         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
2047         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2048         * dfg/DFGCSEPhase.cpp:
2049         (JSC::DFG::CSEPhase::run):
2050         (JSC::DFG::CSEPhase::setReplacement):
2051         (JSC::DFG::CSEPhase::performBlockCSE):
2052         * dfg/DFGGraph.cpp:
2053         (DFG):
2054         (JSC::DFG::Graph::clearReplacements):
2055         * dfg/DFGGraph.h:
2056         (JSC::DFG::Graph::performSubstitutionForEdge):
2057         (Graph):
2058         * dfg/DFGNode.h:
2059         (JSC::DFG::Node::Node):
2060         * dfg/DFGSSAConversionPhase.cpp:
2061         (JSC::DFG::SSAConversionPhase::run):
2062
2063 2013-07-16  Filip Pizlo  <fpizlo@apple.com>
2064
2065         fourthTier: NaturalLoops should be able to quickly answer questions like "what loops own this basic block"
2066         https://bugs.webkit.org/show_bug.cgi?id=118750
2067
2068         Reviewed by Mark Hahnenberg.
2069
2070         * dfg/DFGBasicBlock.h:
2071         (BasicBlock):
2072         * dfg/DFGNaturalLoops.cpp:
2073         (JSC::DFG::NaturalLoops::compute):
2074         (JSC::DFG::NaturalLoops::loopsOf):
2075         * dfg/DFGNaturalLoops.h:
2076         (DFG):
2077         (JSC::DFG::NaturalLoop::NaturalLoop):
2078         (NaturalLoop):
2079         (JSC::DFG::NaturalLoop::index):
2080         (JSC::DFG::NaturalLoop::isOuterMostLoop):
2081         (JSC::DFG::NaturalLoop::addBlock):
2082         (JSC::DFG::NaturalLoops::headerOf):
2083         (JSC::DFG::NaturalLoops::innerMostLoopOf):
2084         (NaturalLoops):
2085         (JSC::DFG::NaturalLoops::innerMostOuterLoop):
2086         * dfg/DFGPlan.cpp:
2087         (JSC::DFG::Plan::compileInThreadImpl):
2088
2089 2013-07-16  Filip Pizlo  <fpizlo@apple.com>
2090
2091         fourthTier: don't GC when shutting down the VM
2092         https://bugs.webkit.org/show_bug.cgi?id=118751
2093
2094         Reviewed by Mark Hahnenberg.
2095
2096         * heap/Heap.h:
2097         (Heap):
2098         * runtime/VM.cpp:
2099         (JSC::VM::~VM):
2100
2101 2013-07-12  Filip Pizlo  <fpizlo@apple.com>
2102
2103         fourthTier: DFG should have an SSA form for use by FTL
2104         https://bugs.webkit.org/show_bug.cgi?id=118338
2105
2106         Reviewed by Mark Hahnenberg.
2107         
2108         Adds an SSA form to the DFG. We can convert ThreadedCPS form into SSA form
2109         after breaking critical edges. The conversion algorithm follows Aycock and
2110         Horspool, and the SSA form itself follows something I've done before, where
2111         instead of having Phi functions specify input nodes corresponding to block
2112         predecessors, we instead have Upsilon functions in the predecessors that
2113         specify which value in that block goes into which subsequent Phi. Upsilons
2114         don't have to dominate Phis (usually they don't) and they correspond to a
2115         non-SSA "mov" into the Phi's "variable". This gives all of the good
2116         properties of SSA, while ensuring that a bunch of CFG transformations don't
2117         have to be SSA-aware.
2118         
2119         So far the only DFG phases that are SSA-aware are DCE and CFA. CFG
2120         simplification is probably SSA-aware by default, though I haven't tried it.
2121         Constant folding probably needs a few tweaks, but is likely ready. Ditto
2122         for CSE, though it's not clear that we'd want to use block-local CSE when
2123         we could be doing GVN.
2124         
2125         Currently only the FTL can generate code from the SSA form, and there is no
2126         way to convert from SSA to ThreadedCPS or LoadStore. There probably will
2127         never be such a capability.
2128         
2129         In order to handle OSR exit state in the SSA, we place MovHints at Phi
2130         points. Other than that, you can reconstruct state-at-exit by forward
2131         propagating MovHints. Note that MovHint is the new SetLocal in SSA.
2132         SetLocal and GetLocal only survive into SSA if they are on captured
2133         variables, or in the case of flushes. A "live SetLocal" will be
2134         NodeMustGenerate and will always correspond to a flush. Computing the
2135         state-at-exit requires running SSA liveness analysis, OSR availability
2136         analysis, and flush liveness analysis. The FTL runs all of these prior to
2137         generating code. While OSR exit continues to be tricky, much of the logic
2138         is now factored into separate phases and the backend has to do less work
2139         to reason about what happened outside of the basic block that is being
2140         lowered.
2141         
2142         Conversion from DFG SSA to LLVM SSA is done by ensuring that we generate
2143         code in depth-first order, thus guaranteeing that a node will always be
2144         lowered (and hence have a LValue) before any of the blocks dominated by
2145         that node's block have code generated. For Upsilon/Phi, we just use
2146         alloca's. We could do something more clever there, but it's probably not
2147         worth it, at least not now.
2148         
2149         Finally, while the SSA form is currently only being converted to LLVM IR,
2150         there is nothing that prevents us from considering other backends in the
2151         future - with the caveat that this form is designed to be first lowered to
2152         a lower-level SSA before actual machine code generation commences. So we
2153         ought to either use LLVM (the intended path) or we will have to write our
2154         own SSA low-level backend.
2155         
2156         This runs all of the code that the FTL was known to run previously. No
2157         change in performance for now. But it does open some exciting
2158         possibilities!
2159
2160         * JavaScriptCore.xcodeproj/project.pbxproj:
2161         * bytecode/Operands.h:
2162         (JSC::OperandValueTraits::dump):
2163         (JSC::Operands::fill):
2164         (Operands):
2165         (JSC::Operands::clear):
2166         (JSC::Operands::operator==):
2167         * dfg/DFGAbstractState.cpp:
2168         (JSC::DFG::AbstractState::beginBasicBlock):
2169         (JSC::DFG::setLiveValues):
2170         (DFG):
2171         (JSC::DFG::AbstractState::initialize):
2172         (JSC::DFG::AbstractState::endBasicBlock):
2173         (JSC::DFG::AbstractState::executeEffects):
2174         (JSC::DFG::AbstractState::mergeStateAtTail):
2175         (JSC::DFG::AbstractState::merge):
2176         * dfg/DFGAbstractState.h:
2177         (AbstractState):
2178         * dfg/DFGAdjacencyList.h:
2179         (JSC::DFG::AdjacencyList::justOneChild):
2180         (AdjacencyList):
2181         * dfg/DFGBasicBlock.cpp: Added.
2182         (DFG):
2183         (JSC::DFG::BasicBlock::BasicBlock):
2184         (JSC::DFG::BasicBlock::~BasicBlock):
2185         (JSC::DFG::BasicBlock::ensureLocals):
2186         (JSC::DFG::BasicBlock::isInPhis):
2187         (JSC::DFG::BasicBlock::isInBlock):
2188         (JSC::DFG::BasicBlock::removePredecessor):
2189         (JSC::DFG::BasicBlock::replacePredecessor):
2190         (JSC::DFG::BasicBlock::dump):
2191         (JSC::DFG::BasicBlock::SSAData::SSAData):
2192         (JSC::DFG::BasicBlock::SSAData::~SSAData):
2193         * dfg/DFGBasicBlock.h:
2194         (BasicBlock):
2195         (JSC::DFG::BasicBlock::operator[]):
2196         (JSC::DFG::BasicBlock::successor):
2197         (JSC::DFG::BasicBlock::successorForCondition):
2198         (SSAData):
2199         * dfg/DFGBasicBlockInlines.h:
2200         (DFG):
2201         * dfg/DFGBlockInsertionSet.cpp: Added.
2202         (DFG):
2203         (JSC::DFG::BlockInsertionSet::BlockInsertionSet):
2204         (JSC::DFG::BlockInsertionSet::~BlockInsertionSet):
2205         (JSC::DFG::BlockInsertionSet::insert):
2206         (JSC::DFG::BlockInsertionSet::insertBefore):
2207         (JSC::DFG::BlockInsertionSet::execute):
2208         * dfg/DFGBlockInsertionSet.h: Added.
2209         (DFG):
2210         (BlockInsertionSet):
2211         * dfg/DFGCFAPhase.cpp:
2212         (JSC::DFG::CFAPhase::run):
2213         * dfg/DFGCFGSimplificationPhase.cpp:
2214         * dfg/DFGCPSRethreadingPhase.cpp:
2215         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
2216         * dfg/DFGCommon.cpp:
2217         (WTF::printInternal):
2218         * dfg/DFGCommon.h:
2219         (JSC::DFG::doesKill):
2220         (DFG):
2221         (JSC::DFG::killStatusForDoesKill):
2222         * dfg/DFGConstantFoldingPhase.cpp:
2223         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2224         (JSC::DFG::ConstantFoldingPhase::isCapturedAtOrAfter):
2225         * dfg/DFGCriticalEdgeBreakingPhase.cpp: Added.
2226         (DFG):
2227         (CriticalEdgeBreakingPhase):
2228         (JSC::DFG::CriticalEdgeBreakingPhase::CriticalEdgeBreakingPhase):
2229         (JSC::DFG::CriticalEdgeBreakingPhase::run):
2230         (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
2231         (JSC::DFG::performCriticalEdgeBreaking):
2232         * dfg/DFGCriticalEdgeBreakingPhase.h: Added.
2233         (DFG):
2234         * dfg/DFGDCEPhase.cpp:
2235         (JSC::DFG::DCEPhase::run):
2236         (JSC::DFG::DCEPhase::findTypeCheckRoot):
2237         (JSC::DFG::DCEPhase::countNode):
2238         (DCEPhase):
2239         (JSC::DFG::DCEPhase::countEdge):
2240         (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
2241         * dfg/DFGDriver.cpp:
2242         (JSC::DFG::compile):
2243         * dfg/DFGEdge.cpp:
2244         (JSC::DFG::Edge::dump):
2245         * dfg/DFGEdge.h:
2246         (JSC::DFG::Edge::Edge):
2247         (JSC::DFG::Edge::setNode):
2248         (JSC::DFG::Edge::useKindUnchecked):
2249         (JSC::DFG::Edge::setUseKind):
2250         (JSC::DFG::Edge::setProofStatus):
2251         (JSC::DFG::Edge::willNotHaveCheck):
2252         (JSC::DFG::Edge::willHaveCheck):
2253         (Edge):
2254         (JSC::DFG::Edge::killStatusUnchecked):
2255         (JSC::DFG::Edge::killStatus):
2256         (JSC::DFG::Edge::setKillStatus):
2257         (JSC::DFG::Edge::doesKill):
2258         (JSC::DFG::Edge::doesNotKill):
2259         (JSC::DFG::Edge::shift):
2260         (JSC::DFG::Edge::makeWord):
2261         * dfg/DFGFixupPhase.cpp:
2262         (JSC::DFG::FixupPhase::fixupNode):
2263         * dfg/DFGFlushFormat.cpp: Added.
2264         (WTF):
2265         (WTF::printInternal):
2266         * dfg/DFGFlushFormat.h: Added.
2267         (DFG):
2268         (JSC::DFG::resultFor):
2269         (JSC::DFG::useKindFor):
2270         (WTF):
2271         * dfg/DFGFlushLivenessAnalysisPhase.cpp: Added.
2272         (DFG):
2273         (FlushLivenessAnalysisPhase):
2274         (JSC::DFG::FlushLivenessAnalysisPhase::FlushLivenessAnalysisPhase):
2275         (JSC::DFG::FlushLivenessAnalysisPhase::run):
2276         (JSC::DFG::FlushLivenessAnalysisPhase::process):
2277         (JSC::DFG::FlushLivenessAnalysisPhase::setForNode):
2278         (JSC::DFG::FlushLivenessAnalysisPhase::flushFormat):
2279         (JSC::DFG::performFlushLivenessAnalysis):
2280         * dfg/DFGFlushLivenessAnalysisPhase.h: Added.
2281         (DFG):
2282         * dfg/DFGGraph.cpp:
2283         (JSC::DFG::Graph::dump):
2284         (JSC::DFG::Graph::dumpBlockHeader):
2285         (DFG):
2286         (JSC::DFG::Graph::addForDepthFirstSort):
2287         (JSC::DFG::Graph::getBlocksInDepthFirstOrder):
2288         * dfg/DFGGraph.h:
2289         (JSC::DFG::Graph::convertToConstant):
2290         (JSC::DFG::Graph::valueProfileFor):
2291         (Graph):
2292         * dfg/DFGInsertionSet.h:
2293         (DFG):
2294         (JSC::DFG::InsertionSet::execute):
2295         * dfg/DFGLivenessAnalysisPhase.cpp: Added.
2296         (DFG):
2297         (LivenessAnalysisPhase):
2298         (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
2299         (JSC::DFG::LivenessAnalysisPhase::run):
2300         (JSC::DFG::LivenessAnalysisPhase::process):
2301         (JSC::DFG::LivenessAnalysisPhase::addChildUse):
2302         (JSC::DFG::performLivenessAnalysis):
2303         * dfg/DFGLivenessAnalysisPhase.h: Added.
2304         (DFG):
2305         * dfg/DFGNode.cpp:
2306         (JSC::DFG::Node::hasVariableAccessData):
2307         (DFG):
2308         * dfg/DFGNode.h:
2309         (DFG):
2310         (Node):
2311         (JSC::DFG::Node::hasLocal):
2312         (JSC::DFG::Node::variableAccessData):
2313         (JSC::DFG::Node::hasPhi):
2314         (JSC::DFG::Node::phi):
2315         (JSC::DFG::Node::takenBlock):
2316         (JSC::DFG::Node::notTakenBlock):
2317         (JSC::DFG::Node::successor):
2318         (JSC::DFG::Node::successorForCondition):
2319         (JSC::DFG::nodeComparator):
2320         (JSC::DFG::nodeListDump):
2321         (JSC::DFG::nodeMapDump):
2322         * dfg/DFGNodeFlags.cpp:
2323         (JSC::DFG::dumpNodeFlags):
2324         * dfg/DFGNodeType.h:
2325         (DFG):
2326         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp: Added.
2327         (DFG):
2328         (OSRAvailabilityAnalysisPhase):
2329         (JSC::DFG::OSRAvailabilityAnalysisPhase::OSRAvailabilityAnalysisPhase):
2330         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
2331         (JSC::DFG::performOSRAvailabilityAnalysis):
2332         * dfg/DFGOSRAvailabilityAnalysisPhase.h: Added.
2333         (DFG):
2334         * dfg/DFGPlan.cpp:
2335         (JSC::DFG::Plan::compileInThreadImpl):
2336         * dfg/DFGPredictionInjectionPhase.cpp:
2337         (JSC::DFG::PredictionInjectionPhase::run):
2338         * dfg/DFGPredictionPropagationPhase.cpp:
2339         (JSC::DFG::PredictionPropagationPhase::propagate):
2340         * dfg/DFGSSAConversionPhase.cpp: Added.
2341         (DFG):
2342         (SSAConversionPhase):
2343         (JSC::DFG::SSAConversionPhase::SSAConversionPhase):
2344         (JSC::DFG::SSAConversionPhase::run):
2345         (JSC::DFG::SSAConversionPhase::forwardPhiChildren):
2346         (JSC::DFG::SSAConversionPhase::forwardPhi):
2347         (JSC::DFG::SSAConversionPhase::forwardPhiEdge):
2348         (JSC::DFG::SSAConversionPhase::deduplicateChildren):
2349         (JSC::DFG::SSAConversionPhase::addFlushedLocalOp):
2350         (JSC::DFG::SSAConversionPhase::addFlushedLocalEdge):
2351         (JSC::DFG::performSSAConversion):
2352         * dfg/DFGSSAConversionPhase.h: Added.
2353         (DFG):
2354         * dfg/DFGSpeculativeJIT32_64.cpp:
2355         (JSC::DFG::SpeculativeJIT::compile):
2356         * dfg/DFGSpeculativeJIT64.cpp:
2357         (JSC::DFG::SpeculativeJIT::compile):
2358         * dfg/DFGValidate.cpp:
2359         (JSC::DFG::Validate::validate):
2360         (Validate):
2361         (JSC::DFG::Validate::validateCPS):
2362         * dfg/DFGVariableAccessData.h:
2363         (JSC::DFG::VariableAccessData::flushFormat):
2364         (VariableAccessData):
2365         * ftl/FTLCapabilities.cpp:
2366         (JSC::FTL::canCompile):
2367         * ftl/FTLLowerDFGToLLVM.cpp:
2368         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
2369         (JSC::FTL::LowerDFGToLLVM::lower):
2370         (JSC::FTL::LowerDFGToLLVM::createPhiVariables):
2371         (JSC::FTL::LowerDFGToLLVM::compileBlock):
2372         (JSC::FTL::LowerDFGToLLVM::compileNode):
2373         (JSC::FTL::LowerDFGToLLVM::compileUpsilon):
2374         (LowerDFGToLLVM):
2375         (JSC::FTL::LowerDFGToLLVM::compilePhi):
2376         (JSC::FTL::LowerDFGToLLVM::compileJSConstant):
2377         (JSC::FTL::LowerDFGToLLVM::compileWeakJSConstant):
2378         (JSC::FTL::LowerDFGToLLVM::compileGetArgument):
2379         (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
2380         (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
2381         (JSC::FTL::LowerDFGToLLVM::compileAdd):
2382         (JSC::FTL::LowerDFGToLLVM::compileArithSub):
2383         (JSC::FTL::LowerDFGToLLVM::compileArithMul):
2384         (JSC::FTL::LowerDFGToLLVM::compileArithDiv):
2385         (JSC::FTL::LowerDFGToLLVM::compileArithMod):
2386         (JSC::FTL::LowerDFGToLLVM::compileArithMinOrMax):
2387         (JSC::FTL::LowerDFGToLLVM::compileArithAbs):
2388         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2389         (JSC::FTL::LowerDFGToLLVM::compileBitAnd):
2390         (JSC::FTL::LowerDFGToLLVM::compileBitOr):
2391         (JSC::FTL::LowerDFGToLLVM::compileBitXor):
2392         (JSC::FTL::LowerDFGToLLVM::compileBitRShift):
2393         (JSC::FTL::LowerDFGToLLVM::compileBitLShift):
2394         (JSC::FTL::LowerDFGToLLVM::compileBitURShift):
2395         (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
2396         (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
2397         (JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
2398         (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
2399         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2400         (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
2401         (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
2402         (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
2403         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
2404         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
2405         (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
2406         (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
2407         (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
2408         (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
2409         (JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
2410         (JSC::FTL::LowerDFGToLLVM::speculateBackward):
2411         (JSC::FTL::LowerDFGToLLVM::lowInt32):
2412         (JSC::FTL::LowerDFGToLLVM::lowCell):
2413         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
2414         (JSC::FTL::LowerDFGToLLVM::lowDouble):
2415         (JSC::FTL::LowerDFGToLLVM::lowJSValue):
2416         (JSC::FTL::LowerDFGToLLVM::lowStorage):
2417         (JSC::FTL::LowerDFGToLLVM::speculate):
2418         (JSC::FTL::LowerDFGToLLVM::speculateBoolean):
2419         (JSC::FTL::LowerDFGToLLVM::isLive):
2420         (JSC::FTL::LowerDFGToLLVM::use):
2421         (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
2422         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
2423         (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
2424         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
2425         (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
2426         (JSC::FTL::LowerDFGToLLVM::setInt32):
2427         (JSC::FTL::LowerDFGToLLVM::setJSValue):
2428         (JSC::FTL::LowerDFGToLLVM::setBoolean):
2429         (JSC::FTL::LowerDFGToLLVM::setStorage):
2430         (JSC::FTL::LowerDFGToLLVM::setDouble):
2431         (JSC::FTL::LowerDFGToLLVM::isValid):
2432         * ftl/FTLLoweredNodeValue.h: Added.
2433         (FTL):
2434         (LoweredNodeValue):
2435         (JSC::FTL::LoweredNodeValue::LoweredNodeValue):
2436         (JSC::FTL::LoweredNodeValue::isSet):
2437         (JSC::FTL::LoweredNodeValue::operator!):
2438         (JSC::FTL::LoweredNodeValue::value):
2439         (JSC::FTL::LoweredNodeValue::block):
2440         * ftl/FTLValueFromBlock.h:
2441         (JSC::FTL::ValueFromBlock::ValueFromBlock):
2442         (ValueFromBlock):
2443         * ftl/FTLValueSource.cpp:
2444         (JSC::FTL::ValueSource::dump):
2445         * ftl/FTLValueSource.h:
2446
2447 2013-07-11  Mark Lam  <mark.lam@apple.com>
2448
2449         Resurrect the CLoop LLINT on the FTL branch.
2450         https://bugs.webkit.org/show_bug.cgi?id=118144.
2451
2452         Reviewed by Mark Hahnenberg.
2453
2454         * bytecode/CodeBlock.h:
2455         (JSC::CodeBlock::jitType):
2456           - Fix the CodeBlock jitType to be InterpreterThunk when !ENABLE_JIT.
2457         * bytecode/JumpTable.h:
2458         (JSC::SimpleJumpTable::clear):
2459         * interpreter/StackIterator.cpp:
2460         (JSC::StackIterator::Frame::bytecodeOffset):
2461         (JSC::StackIterator::Frame::print):
2462         * jit/JITCode.cpp:
2463         (JSC):
2464         * jit/JITExceptions.cpp:
2465         (JSC::getExceptionLocation):
2466         * llint/LowLevelInterpreter.cpp:
2467         * offlineasm/cloop.rb:
2468         * runtime/Structure.cpp:
2469
2470 2013-07-08  Filip Pizlo  <fpizlo@apple.com>
2471
2472         NaturalLoops + Profiler = Crash
2473         https://bugs.webkit.org/show_bug.cgi?id=118486
2474
2475         Reviewed by Geoffrey Garen.
2476         
2477         I borked dominators in:
2478         http://trac.webkit.org/changeset/152431/branches/dfgFourthTier/Source/JavaScriptCore/dfg/DFGDominators.h
2479         
2480         This patch also adds some debug support, and fixes the loop that adds a block to
2481         an already-existing natural loop. Note that we currently don't take that path in
2482         most programs, but it will arise, for example if you use 'continue' - though you'd
2483         have to use it rather cleverly since the bytecode will not jump to the loop header
2484         in most uses of 'continue'.
2485
2486         * dfg/DFGDominators.cpp:
2487         (JSC::DFG::Dominators::dump):
2488         (DFG):
2489         * dfg/DFGDominators.h:
2490         (JSC::DFG::Dominators::dominates):
2491         (Dominators):
2492         * dfg/DFGNaturalLoops.cpp:
2493         (JSC::DFG::NaturalLoops::compute):
2494
2495 2013-07-08  Filip Pizlo  <fpizlo@apple.com>
2496
2497         fourthTier: DFG::AbstractState::beginBasicBlock() should set m_haveStructures if any of the valuesAtHead have either a current known structure or a non-top/non-bottom array modes
2498         https://bugs.webkit.org/show_bug.cgi?id=118489
2499
2500         Reviewed by Mark Hahnenberg.
2501
2502         * bytecode/ArrayProfile.h:
2503         (JSC::arrayModesAreClearOrTop):
2504         (JSC):
2505         * dfg/DFGAbstractState.cpp:
2506         (JSC::DFG::AbstractState::beginBasicBlock):
2507         * dfg/DFGAbstractValue.h:
2508         (JSC::DFG::AbstractValue::hasClobberableState):
2509         (AbstractValue):
2510
2511 2013-07-08  Mark Hahnenberg  <mhahnenberg@apple.com>
2512
2513         CheckArray should call the right version of filterArrayModes
2514         https://bugs.webkit.org/show_bug.cgi?id=118488
2515
2516         Reviewed by Filip Pizlo.
2517
2518         Currently in the CFA CheckArray doesn't call the right filterArrayMode which can cause 
2519         the CFA to ignore when it sees a contradiction.
2520
2521         * dfg/DFGAbstractState.cpp:
2522         (JSC::DFG::AbstractState::executeEffects):
2523
2524 2013-07-07  Filip Pizlo  <fpizlo@apple.com>
2525
2526         fourthTier: Graph::clearAndDerefChild() makes no sense anymore, and neither does Nop
2527         https://bugs.webkit.org/show_bug.cgi?id=118452
2528
2529         Reviewed by Sam Weinig.
2530         
2531         Noticed that ArgumentsSimplificationPhase was converting something to a Nop and then
2532         resetting its children using clearAndDerefChild(). Using Nop instead of Phantom is a
2533         holdover from back when we needed a no-MustGenerate no-op. We don't anymore. Using
2534         clearAndDerefChild() was necessary back when we did eager reference counting. We
2535         don't need to do that anymore, and in fact clearAndDerefChild() appeared to not do
2536         any reference counting, so it was badly named to begin with.
2537
2538         * dfg/DFGAbstractState.cpp:
2539         (JSC::DFG::AbstractState::executeEffects):
2540         * dfg/DFGArgumentsSimplificationPhase.cpp:
2541         (JSC::DFG::ArgumentsSimplificationPhase::run):
2542         * dfg/DFGCPSRethreadingPhase.cpp:
2543         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
2544         * dfg/DFGCSEPhase.cpp:
2545         (JSC::DFG::CSEPhase::performNodeCSE):
2546         * dfg/DFGFixupPhase.cpp:
2547         (JSC::DFG::FixupPhase::fixupNode):
2548         * dfg/DFGGraph.h:
2549         (Graph):
2550         * dfg/DFGNode.h:
2551         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2552         * dfg/DFGNodeType.h:
2553         (DFG):
2554         * dfg/DFGPredictionPropagationPhase.cpp:
2555         (JSC::DFG::PredictionPropagationPhase::propagate):
2556         * dfg/DFGSpeculativeJIT32_64.cpp:
2557         (JSC::DFG::SpeculativeJIT::compile):
2558         * dfg/DFGSpeculativeJIT64.cpp:
2559         (JSC::DFG::SpeculativeJIT::compile):
2560
2561 2013-07-04  Filip Pizlo  <fpizlo@apple.com>
2562
2563         fourthTier: FTL should better report its compile-times and it should be able to run in a mode where it doesn't spend time generating OSR exits
2564         https://bugs.webkit.org/show_bug.cgi?id=118401
2565
2566         Reviewed by Sam Weinig.
2567         
2568         Add two new OSR exit modes, which are useful only for playing with compile times:
2569         
2570         - All OSR exits are llvm.trap().
2571         
2572         - OSR exits don't take arguments and have no exit value marshaling.
2573
2574         * dfg/DFGPlan.cpp:
2575         (JSC::DFG::Plan::compileInThread):
2576         (JSC::DFG::Plan::compileInThreadImpl):
2577         * dfg/DFGPlan.h:
2578         (Plan):
2579         * ftl/FTLIntrinsicRepository.h:
2580         (FTL):
2581         * ftl/FTLLowerDFGToLLVM.cpp:
2582         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
2583         (LowerDFGToLLVM):
2584         (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
2585         * ftl/FTLOutput.h:
2586         (JSC::FTL::Output::trap):
2587         * runtime/Options.h:
2588         (JSC):
2589
2590 2013-07-04  Filip Pizlo  <fpizlo@apple.com>
2591
2592         fourthTier: DFG should refer to BasicBlocks by BasicBlock* and not BlockIndex
2593         https://bugs.webkit.org/show_bug.cgi?id=118339
2594
2595         Reviewed by Michael Saboff.
2596         
2597         This accomplishes two goals:
2598
2599         1) Simplifies a bunch of code. You can now much more directly get to a successor
2600            or predecessor, since you just get the pointer directly. The backend(s) always
2601            hold onto a pointer to the block they're on, so you don't have to do work to
2602            get the block from the index.
2603         
2604         2) It allows for the possibility of inserting blocks into the program.
2605            Previously, if you did that, you'd have to edit all references to blocks since
2606            those references would have outdated indexing after an insertion. Now, if you
2607            change the indexing, you just have to invalidate some analyses and make sure
2608            that you change each block's BasicBlock::index accordingly.
2609
2610         * dfg/DFGAbstractState.cpp:
2611         (JSC::DFG::AbstractState::initialize):
2612         (JSC::DFG::AbstractState::endBasicBlock):
2613         (JSC::DFG::AbstractState::mergeToSuccessors):
2614         * dfg/DFGAbstractState.h:
2615         (AbstractState):
2616         * dfg/DFGArgumentsSimplificationPhase.cpp:
2617         (JSC::DFG::ArgumentsSimplificationPhase::run):
2618         * dfg/DFGBackwardsPropagationPhase.cpp:
2619         (JSC::DFG::BackwardsPropagationPhase::run):
2620         * dfg/DFGBasicBlock.h:
2621         (DFG):
2622         (JSC::DFG::BasicBlock::BasicBlock):
2623         (JSC::DFG::BasicBlock::size):
2624         (JSC::DFG::BasicBlock::isEmpty):
2625         (JSC::DFG::BasicBlock::at):
2626         (JSC::DFG::BasicBlock::operator[]):
2627         (JSC::DFG::BasicBlock::last):
2628         (JSC::DFG::BasicBlock::resize):
2629         (JSC::DFG::BasicBlock::grow):
2630         (BasicBlock):
2631         (JSC::DFG::BasicBlock::append):
2632         (JSC::DFG::BasicBlock::numSuccessors):
2633         (JSC::DFG::BasicBlock::successor):
2634         (JSC::DFG::BasicBlock::successorForCondition):
2635         (JSC::DFG::BasicBlock::dump):
2636         (UnlinkedBlock):
2637         (JSC::DFG::UnlinkedBlock::UnlinkedBlock):
2638         (JSC::DFG::getBytecodeBeginForBlock):
2639         (JSC::DFG::blockForBytecodeOffset):
2640         * dfg/DFGByteCodeParser.cpp:
2641         (ByteCodeParser):
2642         (InlineStackEntry):
2643         (JSC::DFG::ByteCodeParser::handleInlining):
2644         (JSC::DFG::ByteCodeParser::parseBlock):
2645         (JSC::DFG::ByteCodeParser::linkBlock):
2646         (JSC::DFG::ByteCodeParser::linkBlocks):
2647         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2648         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2649         (JSC::DFG::ByteCodeParser::parse):
2650         * dfg/DFGCFAPhase.cpp:
2651         (JSC::DFG::CFAPhase::performBlockCFA):
2652         (JSC::DFG::CFAPhase::performForwardCFA):
2653         * dfg/DFGCFGSimplificationPhase.cpp:
2654         (JSC::DFG::CFGSimplificationPhase::run):
2655         (JSC::DFG::CFGSimplificationPhase::convertToJump):
2656         * dfg/DFGCPSRethreadingPhase.cpp:
2657         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
2658         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks):
2659         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
2660         (CPSRethreadingPhase):
2661         * dfg/DFGCSEPhase.cpp:
2662         (JSC::DFG::CSEPhase::run):
2663         * dfg/DFGConstantFoldingPhase.cpp:
2664         (JSC::DFG::ConstantFoldingPhase::run):
2665         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2666         * dfg/DFGDCEPhase.cpp:
2667         (JSC::DFG::DCEPhase::run):
2668         * dfg/DFGDisassembler.cpp:
2669         (JSC::DFG::Disassembler::Disassembler):
2670         (JSC::DFG::Disassembler::createDumpList):
2671         * dfg/DFGDisassembler.h:
2672         (JSC::DFG::Disassembler::setForBlockIndex):
2673         * dfg/DFGDominators.cpp:
2674         (JSC::DFG::Dominators::compute):
2675         (JSC::DFG::Dominators::iterateForBlock):
2676         * dfg/DFGDominators.h:
2677         (JSC::DFG::Dominators::dominates):
2678         * dfg/DFGFixupPhase.cpp:
2679         (JSC::DFG::FixupPhase::run):
2680         (JSC::DFG::FixupPhase::fixupNode):
2681         * dfg/DFGGraph.cpp:
2682         (JSC::DFG::Graph::dump):
2683         (JSC::DFG::Graph::dumpBlockHeader):
2684         (JSC::DFG::Graph::handleSuccessor):
2685         (JSC::DFG::Graph::determineReachability):
2686         (JSC::DFG::Graph::resetReachability):
2687         * dfg/DFGGraph.h:
2688         (JSC::DFG::Graph::numBlocks):
2689         (JSC::DFG::Graph::block):
2690         (JSC::DFG::Graph::lastBlock):
2691         (Graph):
2692         (JSC::DFG::Graph::appendBlock):
2693         (JSC::DFG::Graph::killBlock):
2694         (DFG):
2695         * dfg/DFGJITCompiler.cpp:
2696         (JSC::DFG::JITCompiler::JITCompiler):
2697         (JSC::DFG::JITCompiler::link):
2698         * dfg/DFGJITCompiler.h:
2699         (JSC::DFG::JITCompiler::setForBlockIndex):
2700         * dfg/DFGNaturalLoops.cpp:
2701         (JSC::DFG::NaturalLoop::dump):
2702         (JSC::DFG::NaturalLoops::compute):
2703         (JSC::DFG::NaturalLoops::loopsOf):
2704         * dfg/DFGNaturalLoops.h:
2705         (JSC::DFG::NaturalLoop::NaturalLoop):
2706         (JSC::DFG::NaturalLoop::addBlock):
2707         (JSC::DFG::NaturalLoop::header):
2708         (JSC::DFG::NaturalLoop::at):
2709         (JSC::DFG::NaturalLoop::operator[]):
2710         (JSC::DFG::NaturalLoop::contains):
2711         (NaturalLoop):
2712         (JSC::DFG::NaturalLoops::headerOf):
2713         (NaturalLoops):
2714         * dfg/DFGNode.h:
2715         (DFG):
2716         (JSC::DFG::SwitchCase::SwitchCase):
2717         (JSC::DFG::SwitchCase::withBytecodeIndex):
2718         (SwitchCase):
2719         (JSC::DFG::SwitchCase::targetBytecodeIndex):
2720         (JSC::DFG::SwitchData::SwitchData):
2721         (JSC::DFG::SwitchData::setFallThroughBytecodeIndex):
2722         (JSC::DFG::SwitchData::fallThroughBytecodeIndex):
2723         (SwitchData):
2724         (JSC::DFG::Node::setTakenBlock):
2725         (JSC::DFG::Node::setNotTakenBlock):
2726         (JSC::DFG::Node::takenBlock):
2727         (JSC::DFG::Node::notTakenBlock):
2728         (JSC::DFG::Node::successor):
2729         (JSC::DFG::Node::successorForCondition):
2730         * dfg/DFGPredictionInjectionPhase.cpp:
2731         (JSC::DFG::PredictionInjectionPhase::run):
2732         * dfg/DFGPredictionPropagationPhase.cpp:
2733         (JSC::DFG::PredictionPropagationPhase::propagateForward):
2734         (JSC::DFG::PredictionPropagationPhase::propagateBackward):
2735         (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
2736         * dfg/DFGSpeculativeJIT.cpp:
2737         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
2738         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompare):
2739         (JSC::DFG::SpeculativeJIT::nonSpeculativeStrictEq):
2740         (JSC::DFG::SpeculativeJIT::compilePeepHoleDoubleBranch):
2741         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
2742         (JSC::DFG::SpeculativeJIT::compilePeepHoleIntegerBranch):
2743         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
2744         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2745         (JSC::DFG::SpeculativeJIT::compile):
2746         (JSC::DFG::SpeculativeJIT::createOSREntries):
2747         (JSC::DFG::SpeculativeJIT::linkOSREntries):
2748         (JSC::DFG::SpeculativeJIT::compileStrictEqForConstant):
2749         (JSC::DFG::SpeculativeJIT::compileStrictEq):
2750         (JSC::DFG::SpeculativeJIT::compileRegExpExec):
2751         (JSC::DFG::SpeculativeJIT::addBranch):
2752         (JSC::DFG::SpeculativeJIT::linkBranches):
2753         * dfg/DFGSpeculativeJIT.h:
2754         (JSC::DFG::SpeculativeJIT::nextBlock):
2755         (SpeculativeJIT):
2756         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
2757         (JSC::DFG::SpeculativeJIT::branchDouble):
2758         (JSC::DFG::SpeculativeJIT::branchDoubleNonZero):
2759         (JSC::DFG::SpeculativeJIT::branch32):
2760         (JSC::DFG::SpeculativeJIT::branchTest32):
2761         (JSC::DFG::SpeculativeJIT::branch64):
2762         (JSC::DFG::SpeculativeJIT::branch8):
2763         (JSC::DFG::SpeculativeJIT::branchPtr):
2764         (JSC::DFG::SpeculativeJIT::branchTestPtr):
2765         (JSC::DFG::SpeculativeJIT::branchTest8):
2766         (JSC::DFG::SpeculativeJIT::jump):
2767         (JSC::DFG::SpeculativeJIT::addBranch):
2768         (JSC::DFG::SpeculativeJIT::StringSwitchCase::StringSwitchCase):
2769         (StringSwitchCase):
2770         (JSC::DFG::SpeculativeJIT::BranchRecord::BranchRecord):
2771         (BranchRecord):
2772         * dfg/DFGSpeculativeJIT32_64.cpp:
2773         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
2774         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
2775         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
2776         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
2777         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2778         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2779         (JSC::DFG::SpeculativeJIT::emitBranch):
2780         (JSC::DFG::SpeculativeJIT::compile):
2781         * dfg/DFGSpeculativeJIT64.cpp:
2782         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
2783         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull):
2784         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
2785         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
2786         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2787         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2788         (JSC::DFG::SpeculativeJIT::emitBranch):
2789         (JSC::DFG::SpeculativeJIT::compile):
2790         * dfg/DFGTypeCheckHoistingPhase.cpp:
2791         (JSC::DFG::TypeCheckHoistingPhase::run):
2792         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2793         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2794         (JSC::DFG::TypeCheckHoistingPhase::disableHoistingAcrossOSREntries):
2795         * dfg/DFGUnificationPhase.cpp:
2796         (JSC::DFG::UnificationPhase::run):
2797         * dfg/DFGValidate.cpp:
2798         (JSC::DFG::Validate::validate):
2799         (JSC::DFG::Validate::checkOperand):
2800         (JSC::DFG::Validate::reportValidationContext):
2801         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2802         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2803         * ftl/FTLCapabilities.cpp:
2804         (JSC::FTL::canCompile):
2805         * ftl/FTLLowerDFGToLLVM.cpp:
2806         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
2807         (JSC::FTL::LowerDFGToLLVM::lower):
2808         (JSC::FTL::LowerDFGToLLVM::compileBlock):
2809         (JSC::FTL::LowerDFGToLLVM::compileJump):
2810         (JSC::FTL::LowerDFGToLLVM::compileBranch):
2811         (JSC::FTL::LowerDFGToLLVM::lowBlock):
2812
2813 2013-07-04  Filip Pizlo  <fpizlo@apple.com>
2814
2815         Unreviewed, add a helpful comment for why DCE is needed in the FTL.
2816
2817         I believe I've now twice down the experiment of disabling DCE in the FTL,
2818         only to realize that this can't work, and that DCE is needed. I'd kind of
2819         like to not make that mistake again.
2820
2821         * dfg/DFGPlan.cpp:
2822         (JSC::DFG::Plan::compileInThreadImpl):
2823
2824 2013-07-02  Filip Pizlo  <fpizlo@apple.com>
2825
2826         fourthTier: DFG::Node::m_opInfo2 should also be a uintptr_t
2827         https://bugs.webkit.org/show_bug.cgi?id=118340
2828
2829         Reviewed by Sam Weinig.
2830
2831         * dfg/DFGNode.h:
2832         (JSC::DFG::Node::Node):
2833
2834 2013-07-02  Filip Pizlo  <fpizlo@apple.com>
2835
2836         Unreviewed, fix 32-bit build.
2837
2838         * assembler/MacroAssembler.h:
2839         (JSC::MacroAssembler::comparePtr):
2840         (MacroAssembler):
2841         * dfg/DFGBinarySwitch.cpp:
2842         (JSC::DFG::BinarySwitch::advance):
2843         * dfg/DFGBinarySwitch.h:
2844         (JSC::DFG::BinarySwitch::caseValue):
2845
2846 2013-07-02  Filip Pizlo  <fpizlo@apple.com>
2847
2848         fourthTier: Have fewer Arrayify's
2849         https://bugs.webkit.org/show_bug.cgi?id=118335
2850
2851         Reviewed by Mark Hahnenberg.
2852         
2853         A lot of Arrayify's arise because some program saw Int32 arrays early on in
2854         execution, but then they all got converted to Double arrays and the program
2855         will never see Int32 arrays ever again. Prior to this change you would always
2856         have an Arrayify in this case. But with this change, the first time that an
2857         ArrayProfile is about to go polymorphic in computeUpdatedPrediction(), it
2858         instead forcibly monomorphises itself to the latest-seen structure.
2859         Thereafter it will never again perform this monomorphisation. This is
2860         controlled by ArrayProfile::m_didPerformFirstRunPruning. This is a 5%
2861         speed-up on Kraken/imaging-gaussian-blur with the FTL enabled, and it
2862         unblocks a bunch of stuff we want to do in the future because it makes a
2863         bunch of loops effect-free.
2864         
2865         We will still want to implement Arrayify hoisting in the future, but this is
2866         great anyway because it's better to not have Arrayifications than it is to
2867         have hoisted Arrayifications.
2868
2869         * bytecode/ArrayProfile.cpp:
2870         (JSC::ArrayProfile::computeUpdatedPrediction):
2871         (JSC::ArrayProfile::briefDescription):
2872         (JSC):
2873         (JSC::ArrayProfile::briefDescriptionWithoutUpdating):
2874         * bytecode/ArrayProfile.h:
2875         (JSC::ArrayProfile::ArrayProfile):
2876         (ArrayProfile):
2877
2878 2013-07-02  Filip Pizlo  <fpizlo@apple.com>
2879
2880         fourthTier: add option to disable OSR entry in loops
2881         https://bugs.webkit.org/show_bug.cgi?id=118329
2882
2883         Reviewed by Mark Hahnenberg.
2884         
2885         This adds that option, and also makes the OSR exit reoptimization trigger rely less on
2886         OSR entry failing. Now even if we never attempt OSR entry but our execution counter gets
2887         high after a small number of OSR exits, we will recompile.
2888
2889         * dfg/DFGOSRExitCompilerCommon.cpp:
2890         (JSC::DFG::handleExitCounts):
2891         * dfg/DFGOperations.cpp:
2892         * jit/JITOpcodes.cpp:
2893         (JSC::JIT::emit_op_loop_hint):
2894         (JSC::JIT::emitSlow_op_loop_hint):
2895         * runtime/Options.h:
2896         (JSC):
2897
2898 2013-07-02  Filip Pizlo  <fpizlo@apple.com>
2899
2900         fourthTier: since the FTL disassembly hacks cannot distinguish between code and data, the LLVM disassembler symbol table callback should be able to deal gracefully with arbitrary garbage
2901         https://bugs.webkit.org/show_bug.cgi?id=118313
2902
2903         Reviewed by Mark Hahnenberg.
2904         
2905         Give it a mode where we can still crash on unrecognized reference types, so that we might
2906         implement them in the future, but by default just print some stuff and keep going.
2907
2908         * disassembler/LLVMDisassembler.cpp:
2909         (JSC):
2910         (JSC::symbolLookupCallback):
2911
2912 2013-07-02  Filip Pizlo  <fpizlo@apple.com>
2913
2914         fourthTier: FTL should use the equivalent of llvm opt -O2 by default
2915         https://bugs.webkit.org/show_bug.cgi?id=118311
2916
2917         Reviewed by Mark Hahnenberg.
2918         
2919         Use a PassManagerBuilder instead of rolling our own.
2920         
2921         This boosts our speed-up by another 5% or so.
2922
2923         * ftl/FTLCompile.cpp:
2924         (JSC::FTL::compile):
2925         * runtime/Options.h:
2926         (JSC):
2927
2928 2013-07-01  Filip Pizlo  <fpizlo@apple.com>
2929
2930         fourthTier: FTL should run LICM after AA setup
2931         https://bugs.webkit.org/show_bug.cgi?id=118277
2932
2933         Reviewed by Maciej Stachowiak.
2934         
2935         LICM queries alias analysis. Hence, just like GVN, it should run after
2936         we have set up the alias analysis.
2937
2938         * ftl/FTLCompile.cpp:
2939         (JSC::FTL::compile):
2940
2941 2013-07-01  Filip Pizlo  <fpizlo@apple.com>
2942
2943         fourthTier: FTL should run AA passes before GVN
2944         https://bugs.webkit.org/show_bug.cgi?id=118276
2945
2946         Rubber stamped by Geoffrey Garen.
2947         
2948         These enable load elimination in GVN.
2949         
2950         Immediately gives us a speed-up on a bunch of benchmarks I hacked to run
2951         properly in the FTL. One example is 20% on imaging-gaussian-blur. (Fair
2952         warning: the stock version of that benchmark won't see speed-ups -
2953         probably slow-downs instead - because the FTL can't do OSR entry yet.)
2954         Another example is the findGraphNode function, which now sees a 7%
2955         speed-up, and that's without even doing LICM or other good things.
2956
2957         * ftl/FTLCompile.cpp:
2958         (JSC::FTL::compile):
2959
2960 2013-06-27  Filip Pizlo  <fpizlo@apple.com>
2961
2962         Make Graph::substituteGetLocal() out-of-line
2963
2964         Rubber stamped by Geoffrey Garen.
2965
2966         * dfg/DFGGraph.cpp:
2967         (JSC::DFG::Graph::substituteGetLocal):
2968         (DFG):
2969         * dfg/DFGGraph.h:
2970         (Graph):
2971
2972 2013-06-27  Filip Pizlo  <fpizlo@apple.com>
2973
2974         fourthTier: DFG should know how to find natural loops
2975         https://bugs.webkit.org/show_bug.cgi?id=118152
2976
2977         Reviewed by Mark Hahnenberg.
2978         
2979         There are a bunch of things we can do when we know where the loops are.
2980         Previously we didn't. With this patch, we do.
2981         
2982         This patch adds the classic dominator based natural loop finder.
2983         
2984         The only client of this right now is the DFG::Disassembler. It prints out
2985         a summary of the analysis for each block.
2986         
2987         This will become more important when I do
2988         https://bugs.webkit.org/show_bug.cgi?id=118151, which definitely requires
2989         this kind of analysis, at least if we want to do the optimization over
2990         DFG IR (and I'm pretty sure we do).
2991
2992         * JavaScriptCore.xcodeproj/project.pbxproj:
2993         * dfg/DFGAnalysis.h: Added.
2994         (DFG):
2995         (Analysis):
2996         (JSC::DFG::Analysis::Analysis):
2997         (JSC::DFG::Analysis::invalidate):
2998         (JSC::DFG::Analysis::computeIfNecessary):
2999         (JSC::DFG::Analysis::isValid):
3000         * dfg/DFGCFGSimplificationPhase.cpp:
3001         (JSC::DFG::CFGSimplificationPhase::run):
3002         * dfg/DFGDisassembler.cpp:
3003         (JSC::DFG::Disassembler::createDumpList):
3004         * dfg/DFGDominators.cpp:
3005         (JSC::DFG::Dominators::Dominators):
3006         (JSC::DFG::Dominators::compute):
3007         * dfg/DFGDominators.h:
3008         (Dominators):
3009         * dfg/DFGGraph.cpp:
3010         (JSC::DFG::Graph::dumpBlockHeader):
3011         (JSC::DFG::Graph::invalidateCFG):
3012         (DFG):
3013         * dfg/DFGGraph.h:
3014         (Graph):
3015         * dfg/DFGNaturalLoops.cpp: Added.
3016         (DFG):
3017         (JSC::DFG::NaturalLoop::dump):
3018         (JSC::DFG::NaturalLoops::NaturalLoops):
3019         (JSC::DFG::NaturalLoops::~NaturalLoops):
3020         (JSC::DFG::NaturalLoops::compute):
3021         (JSC::DFG::NaturalLoops::loopsOf):
3022         (JSC::DFG::NaturalLoops::dump):
3023         * dfg/DFGNaturalLoops.h: Added.
3024         (DFG):
3025         (NaturalLoop):
3026         (JSC::DFG::NaturalLoop::NaturalLoop):
3027         (JSC::DFG::NaturalLoop::addBlock):
3028         (JSC::DFG::NaturalLoop::header):
3029         (JSC::DFG::NaturalLoop::size):
3030         (JSC::DFG::NaturalLoop::at):
3031         (JSC::DFG::NaturalLoop::operator[]):
3032         (JSC::DFG::NaturalLoop::contains):
3033         (NaturalLoops):
3034         (JSC::DFG::NaturalLoops::numLoops):
3035         (JSC::DFG::NaturalLoops::loop):
3036         (JSC::DFG::NaturalLoops::headerOf):
3037
3038 2013-06-27  Filip Pizlo  <fpizlo@apple.com>
3039
3040         fourthTier: JSC's disassembly infrastructure should be able to disassemble the code that LLVM generates
3041         https://bugs.webkit.org/show_bug.cgi?id=118148
3042
3043         Reviewed by Anders Carlsson.
3044         
3045         Oh boy. UDis86 cannot disassemble the AVX (or whatever it's called) stuff
3046         that LLVM generates for floating point. So the right decision is to
3047         switch to the LLVM disassembler, right? Wrong!! LLVM's disassembler
3048         cannot disassemble the load-from-absolute-address-into-%rax instructions
3049         that our JIT generates quite a lot of.
3050         
3051         So, this keeps the UDis86 disassembler, but adds the LLVM disassembler,
3052         and requires the caller of disassemble() to hint which one is likely to
3053         be less wrong for the given code.
3054         
3055         Maybe in the future LLVM will catch up to UDis86, but it's definitely not
3056         there right now.
3057         
3058         This now allows us to disassemble all of the code that LLVM generates.
3059
3060         * JavaScriptCore.xcodeproj/project.pbxproj:
3061         * disassembler/Disassembler.cpp:
3062         (JSC::disassemble):
3063         * disassembler/Disassembler.h:
3064         (JSC::tryToDisassemble):
3065         (JSC):
3066         * disassembler/LLVMDisassembler.cpp: Added.
3067         (JSC):
3068         (JSC::symbolLookupCallback):
3069         (JSC::tryToDisassembleWithLLVM):
3070         * disassembler/LLVMDisassembler.h: Added.
3071         (JSC):
3072         (JSC::tryToDisassembleWithLLVM):
3073         * disassembler/UDis86Disassembler.cpp:
3074         (JSC::tryToDisassembleWithUDis86):
3075         * disassembler/UDis86Disassembler.h: Added.
3076         (JSC):
3077         (JSC::tryToDisassembleWithUDis86):
3078         * disassembler/X86Disassembler.cpp: Added.
3079         (JSC):
3080         (JSC::tryToDisassemble):
3081         * ftl/FTLAbbreviatedTypes.h:
3082         * ftl/FTLCompile.cpp:
3083         (JSC::FTL::compile):
3084         * ftl/FTLJITCode.h:
3085         * ftl/FTLJITFinalizer.h:
3086         * ftl/FTLLLVMHeaders.h: Removed.
3087         * ftl/FTLLink.cpp:
3088         * runtime/InitializeThreading.cpp:
3089         (JSC::initializeThreadingOnce):
3090         * runtime/Options.h:
3091         (JSC):
3092
3093 2013-06-27  Filip Pizlo  <fpizlo@apple.com>
3094
3095         fourthTier: FTL should be able to dump disassembly
3096         https://bugs.webkit.org/show_bug.cgi?id=118141
3097
3098         Reviewed by Geoffrey Garen.
3099
3100         * ftl/FTLCompile.cpp:
3101         (JSC::FTL::compile):
3102
3103 2013-06-27  Filip Pizlo  <fpizlo@apple.com>
3104
3105         Unreviewed, fix build for LLVM ToT.
3106
3107         This doesn't affect those using the binary drops, but if you're building from
3108         LLVM ToT you'll get link errors. These arise because we expect there to be a
3109         libLLVMArchive, but that is no longer built by LLVM ToT. This casues the linker
3110         to fall back on the system's libLLVMArchive, which is incompatible with the
3111         other LLVM libs we pull in.
3112         
3113         Also, we didn't need that library anyway and shouldn't have been linking
3114         against it.
3115
3116         * Configurations/JavaScriptCore.xcconfig:
3117
3118 2013-06-26  Filip Pizlo  <fpizlo@apple.com>
3119
3120         fourthTier: FTL should support hole/OOB PutByVal's
3121         https://bugs.webkit.org/show_bug.cgi?id=118112
3122
3123         Reviewed by Geoffrey Garen.
3124         
3125         Added a common code generator for the out-of-bounds case that is reused by
3126         all contiguous-like arrays (Int32, Double, Contiguous).
3127         
3128         This is relatively straight-forward, except that it's the first time that
3129         the FTL has to call DFG operations that take more than two arguments.
3130
3131         * ftl/FTLAbbreviations.h:
3132         (JSC::FTL::functionType):
3133         (JSC::FTL::buildCall):
3134         * ftl/FTLAbstractHeapRepository.h:
3135         (FTL):
3136         * ftl/FTLCapabilities.cpp:
3137         (JSC::FTL::canCompile):
3138         * ftl/FTLIntrinsicRepository.h:
3139         (FTL):
3140         * ftl/FTLLowerDFGToLLVM.cpp:
3141         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
3142         (LowerDFGToLLVM):
3143         (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds):
3144         (JSC::FTL::LowerDFGToLLVM::vmCall):
3145         * ftl/FTLOutput.h:
3146         (JSC::FTL::Output::call):
3147
3148 2013-06-26  Filip Pizlo  <fpizlo@apple.com>
3149
3150         fourthTier: FTL::canCompile(Graph&) should not consider nodes that won't be compiled
3151         https://bugs.webkit.org/show_bug.cgi?id=118097
3152
3153         Reviewed by Mark Hahnenberg.
3154         
3155         This increases coverage to include programs that have unprofiled paths. Those paths will
3156         often have nodes that appear to do untyped speculations, and the FTL sometimes doesn't
3157         support those; except that it doesn't matter since the reason why they were untyped is
3158         that they were unprofiled and anyway we won't run them because we'll exit before them.
3159
3160         * ftl/FTLCapabilities.cpp:
3161         (JSC::FTL::canCompile):
3162
3163 2013-06-26  Filip Pizlo  <fpizlo@apple.com>
3164
3165         fourthTier: FTL should support ArrayifyToStructure
3166         https://bugs.webkit.org/show_bug.cgi?id=118095
3167
3168         Reviewed by Mark Hahnenberg.
3169
3170         * ftl/FTLCapabilities.cpp:
3171         (JSC::FTL::canCompile):
3172         * ftl/FTLIntrinsicRepository.h:
3173         (FTL):
3174         * ftl/FTLLowerDFGToLLVM.cpp:
3175         (JSC::FTL::LowerDFGToLLVM::compileNode):
3176         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
3177         (LowerDFGToLLVM):
3178
3179 2013-06-26  Filip Pizlo  <fpizlo@apple.com>
3180
3181         fourthTier: FTL should support ForwardCheckStructure/ForwardStructureTransitionWatchpoint and doing so shouldn't break V8/crypto
3182         https://bugs.webkit.org/show_bug.cgi?id=118091
3183
3184         Reviewed by Mark Hahnenberg.
3185         
3186         I was going to just add ForwardCheckStructure/ForwardStructureTransitionWatchpoint support,
3187         which is trivial. But doing so increases coverage a lot, and revealed long-standing bugs in
3188         the FTL. I then fixed those bugs, also:
3189         
3190         - The FTL should not attempt to compile a block that is not reachable according to the CFA.
3191           This is analogous to terminating basic block compilation if the CFA becomes !isValid().
3192           Attempting to compile such a block means that you're running on broken CFA state, and the
3193           CFA will become inconsistent with the code you're generating, leading to some
3194           strangeness. For example, the FTL relies on the CFA to tell it that we gave up compiling
3195           a node and hence don't have LValue's for that node (by virtue of us giving up due to
3196           !isValid()). But the CFA's isValid() bit will not be set correctly for blocks that
3197           weren't visited by the CFA at all, and the CFA expects you to know this because it
3198           expects that you already checked BasicBlock::cfaHasVisited.
3199         
3200         - SetLocal needs to change the ValueSource of the operand to indicate that its value has
3201           been stashed in the local (i.e. the "reference" corresponding to the operand in FTL
3202           speak). This is because although OSR exit already knows that the value of the operand is
3203           stored in the Node, and it already knows what LValue corresponds to the node, OSR exit
3204           will also assume that if the Node dies then the value-at-exit for that operand should be
3205           Dead (i.e. jsUndefined). But the Node dying, and the local dying, are two distinct
3206           things; in particular the local always outlives the Node in the case of a SetLocal. So,
3207           we just need to have SetLocal have the ValueSource be BlahInLocal rather than HaveNode,
3208           to ensure that OSR exit knows that the darn thing is really live until the end of the
3209           basic block, as opposed to until whenever the Node dies (which could be at any time).
3210         
3211         - PutByOffset was erroneously storing to an offset from the base object, rather than an
3212           offset from the storage. Note that the storage will be the base object (exactly - i.e.
3213           same node, same value) for inline stores, but will be a distinct thing for out-of-line
3214           stores.
3215         
3216         - At-head set-up of OSR exit state was using ValueInLocals for variables forced double,
3217           when it should have been using DoubleInLocals.
3218
3219         * ftl/FTLCapabilities.cpp:
3220         (JSC::FTL::canCompile):
3221         * ftl/FTLLowerDFGToLLVM.cpp:
3222         (JSC::FTL::LowerDFGToLLVM::compileBlock):
3223         (JSC::FTL::LowerDFGToLLVM::compileNode):
3224         (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
3225         (JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
3226         (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
3227         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
3228
3229 2013-06-26  Filip Pizlo  <fpizlo@apple.com>
3230
3231         fourthTier: FTL should support PutByVal
3232         https://bugs.webkit.org/show_bug.cgi?id=118075
3233
3234         Reviewed by Mark Hahnenberg.
3235
3236         * ftl/FTLCapabilities.cpp:
3237         (JSC::FTL::canCompile):
3238         * ftl/FTLLowerDFGToLLVM.cpp:
3239         (JSC::FTL::LowerDFGToLLVM::lower):
3240         (JSC::FTL::LowerDFGToLLVM::compileNode):
3241         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
3242         (LowerDFGToLLVM):
3243         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
3244
3245 2013-06-25  Filip Pizlo  <fpizlo@apple.com>
3246
3247         fourthTier: Convert versus AsIs should have no bearing on whether we can do the SaneChain optimization for double array GetByVals
3248         https://bugs.webkit.org/show_bug.cgi?id=118028
3249
3250         Reviewed by Sam Weinig.
3251         
3252         The SaneChain optimization allows us to get rid of the NaN check on loading from
3253         a double array, if the result is used in an arithmetic op that wouldn't
3254         distinguish between NaN and undefined. Normally the NaN check would be needed
3255         because NaN is the hole marker.
3256         
3257         The SaneChain optimization definitely requires that you're an Original array,
3258         since we need to watchpoint the array prototype chain. And so it also needs to
3259         be a JSArray, and not an object that has indexed double properties. We also
3260         require an in-bounds access, since the backend is only capable of the
3261         optimization in the in-bounds case (though we could extend it to OOB in the
3262         future). But whether the array is being converted or is as-is isn't relevant.
3263         Either way, if it's a double original array in-bounds access by the time that
3264         the array check (or conversion!) completes, we can do the optimization.
3265         
3266         Ever-so-slight speed-up on Kraken/imaging-gaussian-blur.
3267
3268         * dfg/DFGFixupPhase.cpp:
3269         (JSC::DFG::FixupPhase::fixupNode):
3270
3271 2013-06-25  Filip Pizlo  <fpizlo@apple.com>
3272
3273         fourthTier: DFG should support switch_string
3274         https://bugs.webkit.org/show_bug.cgi?id=117967
3275
3276         Reviewed by Sam Weinig.
3277         
3278         Add a reusable binary switch creator.
3279         
3280         Implement switch on string using three modes:
3281         
3282         - Binary switch on StringImpl* in the case of identifiers.
3283         
3284         - Trie of binary switches on characters in the case of a not-too-big
3285           switch over not-too-big 8-bit strings.
3286         
3287         - Hash lookup if all else fails.
3288         
3289         Anywhere from a 2x to 3x speed-up on microbenchmarks that stress
3290         string switches. 25-35% speed-up on HashMap tests. 4% speed-up on
3291         pdfjs.
3292
3293         * JavaScriptCore.xcodeproj/project.pbxproj:
3294         * bytecode/JumpTable.h:
3295         (StringJumpTable):
3296         (JSC::StringJumpTable::clear):
3297         * dfg/DFGBackwardsPropagationPhase.cpp:
3298         (JSC::DFG::BackwardsPropagationPhase::propagate):
3299         * dfg/DFGBinarySwitch.cpp: Added.
3300         (DFG):
3301         (JSC::DFG::BinarySwitch::BinarySwitch):
3302         (JSC::DFG::BinarySwitch::advance):
3303         (JSC::DFG::BinarySwitch::build):
3304         * dfg/DFGBinarySwitch.h: Added.
3305         (DFG):
3306         (BinarySwitch):
3307         (JSC::DFG::BinarySwitch::caseIndex):
3308         (JSC::DFG::BinarySwitch::caseValue):
3309         (JSC::DFG::BinarySwitch::fallThrough):
3310         (JSC::DFG::BinarySwitch::Case::Case):
3311         (Case):
3312         (JSC::DFG::BinarySwitch::Case::operator<):
3313         (JSC::DFG::BinarySwitch::BranchCode::BranchCode):
3314         (BranchCode):
3315         * dfg/DFGByteCodeParser.cpp:
3316         (JSC::DFG::ByteCodeParser::parseBlock):
3317         * dfg/DFGCapabilities.cpp:
3318         (JSC::DFG::capabilityLevel):
3319         * dfg/DFGFixupPhase.cpp:
3320         (JSC::DFG::FixupPhase::fixupNode):
3321         * dfg/DFGJITCompiler.cpp:
3322         (JSC::DFG::JITCompiler::link):
3323         * dfg/DFGLazyJSValue.cpp:
3324         (JSC::DFG::LazyJSValue::getValue):
3325         (JSC::DFG::equalToStringImpl):
3326         (DFG):
3327         (JSC::DFG::LazyJSValue::strictEqual):
3328         (JSC::DFG::LazyJSValue::dump):
3329         * dfg/DFGLazyJSValue.h:
3330         (JSC::DFG::LazyJSValue::knownStringImpl):
3331         (LazyJSValue):
3332         (JSC::DFG::LazyJSValue::stringImpl):
3333         (JSC::DFG::LazyJSValue::switchLookupValue):
3334         * dfg/DFGNode.cpp:
3335         (WTF::printInternal):
3336         * dfg/DFGNode.h:
3337         * dfg/DFGOperations.cpp:
3338         * dfg/DFGOperations.h:
3339         * dfg/DFGSpeculativeJIT.cpp:
3340         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
3341         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
3342         (DFG):
3343         (JSC::DFG::SpeculativeJIT::emitBinarySwitchStringRecurse):
3344         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
3345         (JSC::DFG::SpeculativeJIT::emitSwitchString):
3346         (JSC::DFG::SpeculativeJIT::emitSwitch):
3347         (JSC::DFG::SpeculativeJIT::addBranch):
3348         * dfg/DFGSpeculativeJIT.h:
3349         (JSC::DFG::SpeculativeJIT::callOperation):
3350         (JSC::DFG::SpeculativeJIT::branch8):
3351         (SpeculativeJIT):
3352         (JSC::DFG::SpeculativeJIT::StringSwitchCase::StringSwitchCase):
3353         (StringSwitchCase):
3354         * ftl/FTLLowerDFGToLLVM.cpp:
3355         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
3356         * runtime/Options.h:
3357         (JSC):
3358
3359 2013-06-24  Filip Pizlo  <fpizlo@apple.com>
3360
3361         fourthTier: Count external memory usage towards heap footprint
3362         https://bugs.webkit.org/show_bug.cgi?id=117948
3363
3364         Reviewed by Geoffrey Garen.
3365