Enforce options coherency
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-12  Basile Clement  <basile_clement@apple.com>
2
3         Enforce options coherency
4         https://bugs.webkit.org/show_bug.cgi?id=144921
5
6         Reviewed by Mark Lam.
7
8         JavaScriptCore should be failing early when the options are set in such
9         a way that we don't have a meaningful way to execute JavaScript, rather
10         than failing for obscure reasons at some point during execution.
11
12         This patch adds a new function that checks whether the options are set
13         in a coherent way, and makes JSC::Options::initialize() crash when the
14         environment enforces incoherent options.
15         Client applications able to add or change additional options are
16         responsible to check for coherency again before starting to actually
17         execute JavaScript, if any additional options have been set. This is
18         implemented for the jsc executable in this patch.
19
20         * jsc.cpp:
21         (CommandLine::parseArguments):
22         * runtime/Options.cpp:
23         (JSC::Options::initialize):
24         (JSC::Options::ensureOptionsAreCoherent): Added.
25         * runtime/Options.h:
26         (JSC::Options::ensureOptionsAreCoherent): Added.
27
28 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
29
30         REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
31         https://bugs.webkit.org/show_bug.cgi?id=145019
32
33         Reviewed by Ryosuke Niwa.
34
35         Attempt to fix compile errors in EFL ARM buildbots.
36         By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
37         unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
38
39         * runtime/JSTemplateRegistryKey.cpp:
40         * runtime/TemplateRegistry.cpp:
41
42 2015-05-14  Alexandr Skachkov  <gskachkov@gmail.com>
43
44         Small refactoring before implementation of the ES6 arrow function.
45         https://bugs.webkit.org/show_bug.cgi?id=144954
46
47         Reviewed by Ryosuke Niwa.
48
49         * parser/Parser.h:
50         * parser/Parser.cpp:
51
52 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
53
54         REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
55         https://bugs.webkit.org/show_bug.cgi?id=145013
56
57         Reviewed by Filip Pizlo.
58
59         Fix the regression introduced by r184337.
60
61         1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
62            JSDestructibleObject::s_info.
63
64         2. The first register argument of BytecodeGenerator::emitNode
65            should be a referenced register if it is a temporary register.
66
67         * bytecompiler/NodesCodegen.cpp:
68         (JSC::TaggedTemplateNode::emitBytecode):
69         * runtime/JSTemplateRegistryKey.cpp:
70
71 2015-05-14  Andreas Kling  <akling@apple.com>
72
73         String.prototype.split() should create efficient substrings.
74         <https://webkit.org/b/144985>
75         <rdar://problem/20949344>
76
77         Reviewed by Geoffrey Garen.
78
79         Teach split() how to make substring JSStrings instead of relying on StringImpl's
80         substring sharing mechanism. The optimization works by deferring the construction
81         of a StringImpl until the substring's value is actually needed.
82
83         This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
84         Out of ~70000 substrings created by split(), only ~2000 of them get reified.
85
86         * runtime/StringPrototype.cpp:
87         (JSC::jsSubstring):
88         (JSC::splitStringByOneCharacterImpl):
89         (JSC::stringProtoFuncSplit):
90
91 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
92
93         Change the status of ES6 tagged templates to Done in features.json
94         https://bugs.webkit.org/show_bug.cgi?id=145003
95
96         Reviewed by Benjamin Poulain.
97
98         Now it's implemented in r184337.
99
100         * features.json:
101
102 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
103
104         Introduce SymbolType into SpeculativeTypes
105         https://bugs.webkit.org/show_bug.cgi?id=142651
106
107         Reviewed by Filip Pizlo.
108
109         Introduce SpecSymbol type into speculative types.
110         Previously symbol type is categorized into SpecCellOther.
111         But SpecCellOther is not intended to be used for such cells.
112
113         This patch just introduces SpecSymbol.
114         It represents the type of target value is definitely the symbol type.
115         It is the part of SpecCell.
116
117         In this patch, we do not introduce SymbolUse tracking.
118         It will be added in the separate patch.
119
120         * bytecode/SpeculatedType.cpp:
121         (JSC::dumpSpeculation):
122         (JSC::speculationFromStructure):
123         * bytecode/SpeculatedType.h:
124         (JSC::isSymbolSpeculation):
125         * dfg/DFGAbstractInterpreterInlines.h:
126         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
127         * dfg/DFGAbstractValue.cpp:
128         (JSC::DFG::AbstractValue::setType):
129         * dfg/DFGConstantFoldingPhase.cpp:
130         (JSC::DFG::ConstantFoldingPhase::foldConstants):
131         * tests/stress/typeof-symbol.js: Added.
132
133 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
134
135         [ES6] Implement tagged templates
136         https://bugs.webkit.org/show_bug.cgi?id=143183
137
138         Reviewed by Oliver Hunt.
139
140         This patch implements ES6 tagged templates.
141         In tagged templates, the function takes the template object.
142
143         The template object contains the raw and cooked template strings,
144         so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
145         While tagged templates require the both strings, the template literal only requires
146         the cooked strings. So when tokenizing under the template literal context,
147         we only builds the cooked strings.
148
149         As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
150         The template objects is cached. And every time we evaluate the same tagged templates,
151         the same (cached) template objects are used.
152         Since the spec freezes this template objects completely,
153         we cannot attach some properties to it.
154         So we can say that it behaves as if the template objects are the primitive values (like JSString).
155         Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
156         As the result, when there is no reference to the template object, we can garbage collect it
157         because the user has no way to test that the newly created template object does not equal
158         to the already collected template object.
159
160         So, to implement tagged templates, we implement the following components.
161
162         1. JSTemplateRegistryKey
163         It holds the template registry key and it does not exposed to users.
164         TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
165         When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
166         we use this JSTemplateRegistryKey as a key to the map and look up the template object from
167         TemplateRegistry.
168         JSTemplateRegistryKey is created at the bytecode compiling time and
169         stored in the CodeBlock as like as JSString content values.
170
171         2. TemplateRegistry
172         This manages the cached template objects.
173         It holds the weak map (JSTemplateRegistryKey -> the template object).
174         The template object is weakly referenced.
175         So if there is no reference to the template object,
176         the template object is automatically GC-ed.
177         When looking up the template object, it searches the cached template object.
178         If it is found, it is returned to the users.
179         If there is no cached template objects, it creates the new template object and
180         stores it with the given template registry key.
181
182         * CMakeLists.txt:
183         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
184         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
185         * JavaScriptCore.xcodeproj/project.pbxproj:
186         * bytecompiler/BytecodeGenerator.cpp:
187         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
188         (JSC::BytecodeGenerator::emitGetTemplateObject):
189         * bytecompiler/BytecodeGenerator.h:
190         * bytecompiler/NodesCodegen.cpp:
191         (JSC::TaggedTemplateNode::emitBytecode):
192         (JSC::TemplateLiteralNode::emitBytecode): Deleted.
193         * parser/ASTBuilder.h:
194         (JSC::ASTBuilder::createTaggedTemplate):
195         (JSC::ASTBuilder::createTemplateLiteral): Deleted.
196         * parser/Lexer.cpp:
197         (JSC::Lexer<T>::setCode):
198         (JSC::Lexer<T>::parseTemplateLiteral):
199         (JSC::Lexer<T>::lex):
200         (JSC::Lexer<T>::scanTrailingTemplateString):
201         (JSC::Lexer<T>::clear):
202         * parser/Lexer.h:
203         (JSC::Lexer<T>::makeEmptyIdentifier):
204         * parser/NodeConstructors.h:
205         (JSC::TaggedTemplateNode::TaggedTemplateNode):
206         (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
207         * parser/Nodes.h:
208         (JSC::TemplateLiteralNode::templateStrings):
209         (JSC::TemplateLiteralNode::templateExpressions):
210         (JSC::TaggedTemplateNode::templateLiteral):
211         * parser/Parser.cpp:
212         (JSC::Parser<LexerType>::parseTemplateString):
213         (JSC::Parser<LexerType>::parseTemplateLiteral):
214         (JSC::Parser<LexerType>::parsePrimaryExpression):
215         (JSC::Parser<LexerType>::parseMemberExpression):
216         * parser/Parser.h:
217         * parser/ParserArena.h:
218         (JSC::IdentifierArena::makeEmptyIdentifier):
219         * parser/SyntaxChecker.h:
220         (JSC::SyntaxChecker::createTaggedTemplate):
221         (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
222         * runtime/CommonIdentifiers.h:
223         * runtime/JSGlobalObject.cpp:
224         (JSC::getTemplateObject):
225         (JSC::JSGlobalObject::JSGlobalObject):
226         (JSC::JSGlobalObject::init):
227         * runtime/JSGlobalObject.h:
228         (JSC::JSGlobalObject::templateRegistry):
229         * runtime/JSTemplateRegistryKey.cpp: Added.
230         (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
231         (JSC::JSTemplateRegistryKey::create):
232         (JSC::JSTemplateRegistryKey::destroy):
233         * runtime/JSTemplateRegistryKey.h: Added.
234         * runtime/ObjectConstructor.cpp:
235         (JSC::objectConstructorFreeze):
236         * runtime/ObjectConstructor.h:
237         * runtime/TemplateRegistry.cpp: Added.
238         (JSC::TemplateRegistry::TemplateRegistry):
239         (JSC::TemplateRegistry::getTemplateObject):
240         * runtime/TemplateRegistry.h: Added.
241         * runtime/TemplateRegistryKey.h: Added.
242         (JSC::TemplateRegistryKey::isDeletedValue):
243         (JSC::TemplateRegistryKey::isEmptyValue):
244         (JSC::TemplateRegistryKey::hash):
245         (JSC::TemplateRegistryKey::rawStrings):
246         (JSC::TemplateRegistryKey::cookedStrings):
247         (JSC::TemplateRegistryKey::operator==):
248         (JSC::TemplateRegistryKey::operator!=):
249         (JSC::TemplateRegistryKey::Hasher::hash):
250         (JSC::TemplateRegistryKey::Hasher::equal):
251         (JSC::TemplateRegistryKey::TemplateRegistryKey):
252         * runtime/VM.cpp:
253         (JSC::VM::VM):
254         * runtime/VM.h:
255         * tests/stress/tagged-templates-identity.js: Added.
256         (shouldBe):
257         * tests/stress/tagged-templates-raw-strings.js: Added.
258         (shouldBe):
259         (tag):
260         (testEval):
261         * tests/stress/tagged-templates-syntax.js: Added.
262         (tag):
263         (testSyntax):
264         (testSyntaxError):
265         * tests/stress/tagged-templates-template-object.js: Added.
266         (shouldBe):
267         (tag):
268         * tests/stress/tagged-templates-this.js: Added.
269         (shouldBe):
270         (tag):
271         * tests/stress/tagged-templates.js: Added.
272         (shouldBe):
273         (raw):
274         (cooked):
275         (Counter):
276
277 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
278
279         REGRESSION(r180595): same-callee profiling no longer works
280         https://bugs.webkit.org/show_bug.cgi?id=144787
281
282         Reviewed by Filip Pizlo.
283
284         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
285         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
286         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
287
288         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
289         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
290         our speculation that the callee is the same. To avoid recompiling the same code for different callee
291         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
292         LLint and baseline JIT when multiple callees are observed.
293
294         Tests: stress/create-this-with-callee-variants.js
295
296         * bytecode/BytecodeList.json: Increased the number of operands to 5.
297         * bytecode/CodeBlock.cpp:
298         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
299         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
300         * bytecompiler/BytecodeGenerator.cpp:
301         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
302         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
303         operand.
304         * dfg/DFGByteCodeParser.cpp:
305         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
306         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
307         * jit/JITOpcodes.cpp:
308         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
309         as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
310         (JSC::JIT::emitSlow_op_create_this):
311         * jit/JITOpcodes32_64.cpp:
312         (JSC::JIT::emit_op_create_this): Ditto.
313         (JSC::JIT::emitSlow_op_create_this):
314         * llint/LowLevelInterpreter32_64.asm:
315         (_llint_op_create_this): Ditto.
316         * llint/LowLevelInterpreter64.asm:
317         (_llint_op_create_this): Ditto.
318         * runtime/CommonSlowPaths.cpp:
319         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
320         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
321         * runtime/JSCell.h:
322         (JSC::JSCell::seenMultipleCalleeObjects): Added.
323         * runtime/WriteBarrier.h:
324         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
325         * tests/stress/create-this-with-callee-variants.js: Added.
326
327 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
328
329         Clean up some possible RefPtr to PassRefPtr churn
330         https://bugs.webkit.org/show_bug.cgi?id=144779
331
332         Reviewed by Darin Adler.
333
334         * runtime/GenericTypedArrayViewInlines.h:
335         (JSC::GenericTypedArrayView<Adaptor>::create):
336         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
337         * runtime/JSArrayBufferConstructor.cpp:
338         (JSC::constructArrayBuffer):
339         * runtime/Structure.cpp:
340         (JSC::Structure::toStructureShape):
341         * runtime/TypedArrayBase.h:
342         (JSC::TypedArrayBase::create):
343         (JSC::TypedArrayBase::createUninitialized):
344         * tools/FunctionOverrides.cpp:
345         (JSC::initializeOverrideInfo):
346         Release the last use of a RefPtr as it is passed on.
347
348 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
349
350         ES6: Allow duplicate property names
351         https://bugs.webkit.org/show_bug.cgi?id=142895
352
353         Reviewed by Geoffrey Garen.
354
355         Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
356         that will define a single getter or setter property on an object.
357
358         The existing `op_put_getter_setter` opcode is still preferred for
359         putting both a getter and setter at the same time but cannot be used
360         for putting an individual getter or setter which is needed in
361         some cases.
362
363         Add a new slow path when generating bytecodes for a property list
364         with computed properties, as computed properties are the only time
365         the list of properties cannot be determined statically.
366
367         * bytecompiler/NodesCodegen.cpp:
368         (JSC::PropertyListNode::emitBytecode):
369         - fast path for all constant properties
370         - slow but paired getter/setter path if there are no computed properties
371         - slow path, individual put operation for every property, if there are computed properties
372
373         * parser/Nodes.h:
374         Distinguish a Computed property from a Constant property.
375
376         * parser/Parser.cpp:
377         (JSC::Parser<LexerType>::parseProperty):
378         (JSC::Parser<LexerType>::parsePropertyMethod):
379         Distingish Computed and Constant properties.
380
381         (JSC::Parser<LexerType>::parseObjectLiteral):
382         When we drop into strict mode it is because we saw a getter
383         or setter, so be more explicit.
384
385         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
386         Eliminate duplicate property syntax error exception.
387
388         * parser/SyntaxChecker.h:
389         (JSC::SyntaxChecker::getName):
390         * parser/ASTBuilder.h:
391         (JSC::ASTBuilder::getName): Deleted.
392         No longer used.
393
394         * runtime/JSObject.h:
395         (JSC::JSObject::putDirectInternal):
396         When updating a property. If the Accessor attribute changed
397         update the Structure.
398
399         * runtime/JSObject.cpp:
400         (JSC::JSObject::putGetter):
401         (JSC::JSObject::putSetter):
402         Called by the opcodes, just perform the same operation that
403         __defineGetter__ or __defineSetter__ would do.
404
405         (JSC::JSObject::putDirectNonIndexAccessor):
406         This transition is now handled in putDirectInternal.
407
408         * runtime/Structure.h:
409         Add needed export.
410
411         * bytecode/BytecodeList.json:
412         * bytecode/BytecodeUseDef.h:
413         (JSC::computeUsesForBytecodeOffset):
414         (JSC::computeDefsForBytecodeOffset):
415         * bytecode/CodeBlock.cpp:
416         (JSC::CodeBlock::dumpBytecode):
417         * bytecompiler/BytecodeGenerator.cpp:
418         (JSC::BytecodeGenerator::emitPutGetterById):
419         (JSC::BytecodeGenerator::emitPutSetterById):
420         * bytecompiler/BytecodeGenerator.h:
421         * jit/JIT.cpp:
422         (JSC::JIT::privateCompileMainPass):
423         * jit/JIT.h:
424         * jit/JITInlines.h:
425         (JSC::JIT::callOperation):
426         * jit/JITOperations.cpp:
427         * jit/JITOperations.h:
428         * jit/JITPropertyAccess.cpp:
429         (JSC::JIT::emit_op_put_getter_by_id):
430         (JSC::JIT::emit_op_put_setter_by_id):
431         * jit/JITPropertyAccess32_64.cpp:
432         (JSC::JIT::emit_op_put_getter_by_id):
433         (JSC::JIT::emit_op_put_setter_by_id):
434         * llint/LLIntSlowPaths.cpp:
435         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
436         * llint/LLIntSlowPaths.h:
437         * llint/LowLevelInterpreter.asm:
438         New bytecodes. Modelled after existing op_put_getter_setter.
439
440 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
441
442         Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
443         https://bugs.webkit.org/show_bug.cgi?id=144856
444
445         Reviewed by Benjamin Poulain.
446         
447         First I made fixTypeForRepresentation() print out better diagnostics when it dies.
448         
449         Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
450         converts to a representation-changing node, it needs to use one of the UseKinds that such
451         a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
452         something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
453
454         * dfg/DFGAbstractInterpreter.h:
455         (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
456         * dfg/DFGAbstractInterpreterInlines.h:
457         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
458         * dfg/DFGAbstractValue.cpp:
459         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
460         * dfg/DFGAbstractValue.h:
461         * dfg/DFGInPlaceAbstractState.cpp:
462         (JSC::DFG::InPlaceAbstractState::initialize):
463         * dfg/DFGNode.cpp:
464         (JSC::DFG::Node::convertToIdentityOn):
465         * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
466         (foo):
467
468 2015-05-13  Commit Queue  <commit-queue@webkit.org>
469
470         Unreviewed, rolling out r184313.
471         https://bugs.webkit.org/show_bug.cgi?id=144974
472
473         Introduced an assertion failure in class-syntax-
474         declaration.js, class-syntax-expression.js, and object-
475         literal-syntax.js (Requested by rniwa on #webkit).
476
477         Reverted changeset:
478
479         "Small refactoring before ES6 Arrow function implementation."
480         https://bugs.webkit.org/show_bug.cgi?id=144954
481         http://trac.webkit.org/changeset/184313
482
483 2015-05-13  Oliver Hunt  <oliver@apple.com>
484         Ensure that all the smart pointer types in WTF clear their pointer before deref
485         https://bugs.webkit.org/show_bug.cgi?id=143789
486
487         Reviewed by Ryosuke Niwa.
488
489         One of the simpler cases of this in JavaScriptCore. There
490         are other cases where we need to guard the derefs but they
491         are more complex cases.
492
493         * inspector/JSInjectedScriptHost.cpp:
494         (Inspector::JSInjectedScriptHost::releaseImpl):
495         * inspector/JSJavaScriptCallFrame.cpp:
496         (Inspector::JSJavaScriptCallFrame::releaseImpl):
497
498 2015-05-13  Alexandr Skachkov  <gskachkov@gmail.com>
499
500         Small refactoring before ES6 Arrow function implementation.
501         https://bugs.webkit.org/show_bug.cgi?id=144954
502
503         Reviewed by Filip Pizlo.
504
505         * parser/Parser.h:
506         * parser/Parser.cpp:
507
508 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
509
510         The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
511         https://bugs.webkit.org/show_bug.cgi?id=144945
512
513         Reviewed by Michael Saboff.
514         
515         We were making the mistake of using DFG liveness for object allocation sinking decisions.
516         This is wrong. In fact we almost never want to use DFG liveness directly. The only place
517         where that makes sense is pruning in DFG AI.
518         
519         So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
520         liveness.
521         
522         In the process of doing this, I realized that the DFGForAllKills definition of combined
523         liveness at block tail was not strictly right; it was using the bytecode liveness at the
524         block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
525         I changed DFGForAllKills to work in terms of CombinedLiveness.
526         
527         This allows me to unskip the test I added in r184260. I also added a new test that tries to
528         trigger this bug more directly.
529
530         * CMakeLists.txt:
531         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
532         * JavaScriptCore.xcodeproj/project.pbxproj:
533         * dfg/DFGArgumentsEliminationPhase.cpp:
534         * dfg/DFGCombinedLiveness.cpp: Added.
535         (JSC::DFG::liveNodesAtHead):
536         (JSC::DFG::CombinedLiveness::CombinedLiveness):
537         * dfg/DFGCombinedLiveness.h: Added.
538         (JSC::DFG::CombinedLiveness::CombinedLiveness):
539         * dfg/DFGForAllKills.h:
540         (JSC::DFG::forAllKillsInBlock):
541         (JSC::DFG::forAllLiveNodesAtTail): Deleted.
542         * dfg/DFGObjectAllocationSinkingPhase.cpp:
543         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
544         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
545         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
546         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
547         * tests/stress/escape-object-in-diamond-then-exit.js: Added.
548         * tests/stress/sink-object-past-invalid-check-sneaky.js:
549
550 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
551
552         I skipped a wrong test in r184270. Fix that.
553         The failure is tracked by webkit.org/b/144947.
554
555         * tests/stress/arith-modulo-node-behaviors.js:
556         * tests/stress/arith-mul-with-constants.js:
557
558 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
559
560         Avoid always running some debug code in type profiling
561         https://bugs.webkit.org/show_bug.cgi?id=144775
562
563         Reviewed by Daniel Bates.
564
565         * runtime/TypeProfilerLog.cpp:
566         (JSC::TypeProfilerLog::processLogEntries):
567
568 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
569
570         Pass String as reference in more places
571         https://bugs.webkit.org/show_bug.cgi?id=144769
572
573         Reviewed by Daniel Bates.
574
575         * debugger/Breakpoint.h:
576         (JSC::Breakpoint::Breakpoint):
577         * parser/Parser.h:
578         (JSC::Parser::setErrorMessage):
579         (JSC::Parser::updateErrorWithNameAndMessage):
580         * parser/ParserError.h:
581         (JSC::ParserError::ParserError):
582         * runtime/RegExp.cpp:
583         (JSC::RegExpFunctionalTestCollector::outputOneTest):
584         * runtime/RegExpObject.cpp:
585         (JSC::regExpObjectSourceInternal):
586         * runtime/TypeProfiler.cpp:
587         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
588         * runtime/TypeProfilerLog.cpp:
589         (JSC::TypeProfilerLog::processLogEntries):
590         * runtime/TypeProfilerLog.h:
591         * tools/FunctionOverrides.cpp:
592         (JSC::initializeOverrideInfo):
593         * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
594         (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
595
596         * inspector/scripts/codegen/objc_generator_templates.py:
597         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
598         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
599         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
600         * inspector/scripts/tests/expected/enum-values.json-result:
601         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
602         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
603         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
604         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
605         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
606         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
607         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
608         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
609         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
610         Rebaseline tests after updating the generator.
611
612 2015-05-13  Michael Saboff  <msaboff@apple.com>
613
614         com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
615         https://bugs.webkit.org/show_bug.cgi?id=144933
616
617         Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT.  Added some diagnostic messages to
618         help determine the cause for any crash.
619
620         Reviewed by Geoffrey Garen.
621
622         * bytecode/CodeBlock.cpp:
623         (JSC::CodeBlock::finalizeUnconditionally):
624
625 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
626
627         REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
628         https://bugs.webkit.org/show_bug.cgi?id=144951
629
630         Reviewed by Michael Saboff.
631         
632         There were two issues here:
633         
634         - In r184260 we expected a small number of possible use kinds in Check nodes, and
635           UntypedUse was not one of them. That seemed like a sensible assumption because we don't
636           create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
637           Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
638           follow the same idiom as everyone else and not create tautological checks.
639         
640         - It's clearly not very robust to assume that Checks will not be used tautologically. So,
641           this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
642           which catches cases that AI would have already marked as unnecessary. It then also uses
643           a new helper called alreadyChecked(), which allows us to just ask if the check is
644           unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
645
646         * dfg/DFGArgumentsEliminationPhase.cpp:
647         * dfg/DFGMayExit.cpp:
648         * dfg/DFGObjectAllocationSinkingPhase.cpp:
649         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
650         * dfg/DFGSSAConversionPhase.cpp:
651         (JSC::DFG::SSAConversionPhase::run):
652         * dfg/DFGUseKind.h:
653         (JSC::DFG::alreadyChecked):
654         * dfg/DFGVarargsForwardingPhase.cpp:
655
656 k
657 2015-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
658
659         [ES6] Implement String.raw
660         https://bugs.webkit.org/show_bug.cgi?id=144330
661
662         Reviewed by Filip Pizlo.
663
664         Implement String.raw. It is intended to be used with tagged-templates syntax.
665         To implement ToString abstract operation efficiently,
666         we introduce @toString bytecode intrinsic. It emits op_to_string directly.
667
668         * CMakeLists.txt:
669         * builtins/StringConstructor.js: Added.
670         (raw):
671         * bytecompiler/NodesCodegen.cpp:
672         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
673         * runtime/CommonIdentifiers.h:
674         * runtime/StringConstructor.cpp:
675         * tests/stress/string-raw.js: Added.
676         (shouldBe):
677         (.get shouldBe):
678         (Counter):
679
680 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
681
682         Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
683
684         * tests/stress/arith-mul-with-constants.js:
685
686 2015-05-12  Filip Pizlo  <fpizlo@apple.com>
687
688         js/dom/stack-trace.html fails with eager compilation
689         https://bugs.webkit.org/show_bug.cgi?id=144853
690
691         Reviewed by Benjamin Poulain.
692         
693         All of our escape analyses were mishandling Check(). They were assuming that this is a
694         non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
695         candidate, then we need to do something: if we eliminate or sink @x, then the check no
696         longer makes any sense since a phantom allocation has no type. This will make us forget
697         that this operation would have exited. This was causing us to not call a valueOf method in
698         js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
699         +o where o had a valueOf method, and o was otherwise sinkable.
700         
701         This changes our escape analyses to basically pretend that any Check() that isn't obviously
702         unnecessary is an escape. We don't have to be super careful here. Most checks will be
703         completely eliminated by constant-folding. If that doesn't run in time, then the most
704         common check we will see is CellUse. So, we just recognize some very obvious check kinds
705         that we know would have passed, and for all of the rest we just assume that it's an escape.
706         
707         This was super tricky to test. The obvious way to test it is to use +o like
708         stack-trace.html, except that doing so relies on the fact that we still haven't implemented
709         the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
710         
711         1) Use +o. These will test what we want it to test for now, but at some point in the future
712            these tests will just be a good sanity-check that our op_to_number implementation is
713            right.
714         
715         2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
716            operation always sees integers even though we eventually feed it an object and that
717            object is a sink candidate.
718         
719         3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
720            value is an int32. This intrinsic is required to be implemented by DFG by
721            unconditionally speculating that the input is int32. This allows us to write much more
722            targetted tests of the underlying issue.
723         
724         4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
725            get regression test coverage of this test in eager mode.
726
727         * dfg/DFGArgumentsEliminationPhase.cpp:
728         * dfg/DFGByteCodeParser.cpp:
729         (JSC::DFG::ByteCodeParser::handleIntrinsic):
730         * dfg/DFGObjectAllocationSinkingPhase.cpp:
731         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
732         * dfg/DFGVarargsForwardingPhase.cpp:
733         * ftl/FTLExitValue.cpp:
734         (JSC::FTL::ExitValue::dumpInContext):
735         * ftl/FTLLowerDFGToLLVM.cpp:
736         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
737         * ftl/FTLOSRExitCompiler.cpp:
738         (JSC::FTL::compileFTLOSRExit):
739         * jsc.cpp:
740         (GlobalObject::finishCreation):
741         (functionIsInt32):
742         * runtime/Intrinsic.h:
743         * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
744         * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
745         * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
746         * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
747         * tests/stress/sink-arguments-past-invalid-check.js: Added.
748         * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
749         * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
750         * tests/stress/sink-object-past-invalid-check-int32.js: Added.
751         * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
752         * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
753         * tests/stress/sink-object-past-invalid-check.js: Added.
754
755 2015-05-12  Benjamin Poulain  <benjamin@webkit.org>
756
757         Fix the iteration count of arith-modulo-node-behaviors.js
758
759         * tests/stress/arith-modulo-node-behaviors.js:
760         No need for big numbers for the real testing.
761
762 2015-05-12  Mark Lam  <mark.lam@apple.com>
763
764         Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
765         https://bugs.webkit.org/show_bug.cgi?id=144924
766
767         Reviewed by Alex Christensen.
768
769         The present stack scanning code in the Windows port is expecting that the
770         GetCurrentThread() API will provide a unique HANDLE for each thread.  The code
771         then saves and later uses that HANDLE with GetThreadContext() to get the
772         runtime state of the target thread from the GC thread.  According to
773         https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
774         GetCurrentThread() does not provide this unique HANDLE that we expect:
775
776             "The function cannot be used by one thread to create a handle that can
777             be used by other threads to refer to the first thread. The handle is
778             always interpreted as referring to the thread that is using it. A
779             thread can create a "real" handle to itself that can be used by other
780             threads, or inherited by other processes, by specifying the pseudo
781             handle as the source handle in a call to the DuplicateHandle function."
782
783         As a result of this, GetCurrentThread() always returns the same HANDLE value, and
784         we end up never scanning the stacks of other threads because we wrongly think that
785         they are all equal (in identity) to the scanning thread.  This, in turn, results
786         in crashes due to objects that are incorrectly collected.
787
788         The fix is to call DuplicateHandle() to create a HANDLE that we can use.  The
789         MachineThreads::Thread class already accurately tracks the period of time when
790         we need that HANDLE for the VM.  Hence, the life-cycle of the HANDLE can be tied
791         to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
792
793         * heap/MachineStackMarker.cpp:
794         (JSC::getCurrentPlatformThread):
795         (JSC::MachineThreads::Thread::Thread):
796         (JSC::MachineThreads::Thread::~Thread):
797         (JSC::MachineThreads::Thread::suspend):
798         (JSC::MachineThreads::Thread::resume):
799         (JSC::MachineThreads::Thread::getRegisters):
800
801 2015-05-12  Benjamin Poulain  <bpoulain@apple.com>
802
803         [JSC] Make the NegZero backward propagated flags of ArithMod stricter
804         https://bugs.webkit.org/show_bug.cgi?id=144897
805
806         Reviewed by Geoffrey Garen.
807
808         The NegZero flags of ArithMod were the same as ArithDiv: both children were
809         marked as needing to handle NegativeZero.
810
811         Lucky for us, ArithMod is quite a bit different than ArithDiv.
812
813         First, the sign of the result is completely independent from
814         the sign of the divisor. A zero on the divisor always produces a NaN.
815         That's great, we can remove the NodeBytecodeNeedsNegZero
816         from the flags propagated to child2.
817
818         Second, the sign of the result is always the same as the sign of
819         the dividend. A dividend of zero produces a zero of same sign
820         unless the divisor is zero (in which case the result is NaN).
821         This is great too: we can just pass the flags we got into
822         ArithMod.
823
824         With those two out of the way, we can make a faster version of ArithRound
825         for Kraken's oscillator. Since we no longer care about negative zero,
826         rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
827         on the benchmark.
828
829         Unfortunatelly, most of the time is spent in FTL and the same optimization
830         does not apply well just yet: rdar://problem/20904149.
831
832         * dfg/DFGBackwardsPropagationPhase.cpp:
833         (JSC::DFG::BackwardsPropagationPhase::propagate):
834         Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
835
836         * dfg/DFGSpeculativeJIT.cpp:
837         (JSC::DFG::SpeculativeJIT::compileArithRound):
838         Faster Math.round() when negative zero is not important.
839
840         * tests/stress/arith-modulo-node-behaviors.js: Added.
841         (moduloWithNegativeZeroDividend):
842         (moduloWithUnusedNegativeZeroDividend):
843         (moduloWithNegativeZeroDivisor):
844
845 2015-05-12  Mark Lam  <mark.lam@apple.com>
846
847         Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
848         https://bugs.webkit.org/show_bug.cgi?id=144925
849
850         Reviewed by Michael Saboff.
851
852         Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
853         operate on the platformThread value in the MachineThreads::Thread struct.  Instead, we
854         can apply better OO encapsulation and convert all these functions into methods of the
855         MachineThreads::Thread struct.
856
857         This will also make it easier to reason about the fix for
858         https://bugs.webkit.org/show_bug.cgi?id=144924 later.
859
860         * heap/MachineStackMarker.cpp:
861         (JSC::getCurrentPlatformThread):
862         (JSC::MachineThreads::Thread::createForCurrentThread):
863         (JSC::MachineThreads::Thread::operator!=):
864         (JSC::MachineThreads::Thread::operator==):
865         (JSC::MachineThreads::addCurrentThread):
866         (JSC::MachineThreads::removeThreadIfFound):
867         (JSC::MachineThreads::Thread::suspend):
868         (JSC::MachineThreads::Thread::resume):
869         (JSC::MachineThreads::Thread::getRegisters):
870         (JSC::MachineThreads::Thread::Registers::stackPointer):
871         (JSC::MachineThreads::Thread::freeRegisters):
872         (JSC::MachineThreads::Thread::captureStack):
873         (JSC::MachineThreads::tryCopyOtherThreadStack):
874         (JSC::MachineThreads::tryCopyOtherThreadStacks):
875         (JSC::equalThread): Deleted.
876         (JSC::suspendThread): Deleted.
877         (JSC::resumeThread): Deleted.
878         (JSC::getPlatformThreadRegisters): Deleted.
879         (JSC::otherThreadStackPointer): Deleted.
880         (JSC::freePlatformThreadRegisters): Deleted.
881         (JSC::otherThreadStack): Deleted.
882
883 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
884
885         Array.slice should have a fast path like Array.splice
886         https://bugs.webkit.org/show_bug.cgi?id=144901
887
888         Reviewed by Geoffrey Garen.
889
890         Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
891         In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
892
893         * runtime/ArrayPrototype.cpp:
894         (JSC::arrayProtoFuncSlice):
895         * runtime/JSArray.cpp:
896         (JSC::JSArray::fastSlice): Added.
897         * runtime/JSArray.h:
898
899 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
900
901         OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
902         https://bugs.webkit.org/show_bug.cgi?id=143078
903
904         Reviewed by Andreas Kling.
905         
906         In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
907         pruning is actually necessary. Well, not quite: we just need to prune out keys from the
908         heap availability map where the base node doesn't dominate the point where we are asking
909         for availability. If we don't do this, then eventually the IR gets corrupt because we'll
910         insert PutHints that reference the base node in places where the base node doesn't
911         dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
912         liveness. This is the strongest possible pruning we can do, and it should be sound. We
913         shouldn't have a node available for a virtual register if that register is live and the
914         node doesn't dominate.
915         
916         Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
917         abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
918
919         * dfg/DFGAvailabilityMap.cpp:
920         (JSC::DFG::AvailabilityMap::pruneHeap):
921         (JSC::DFG::AvailabilityMap::pruneByLiveness):
922         (JSC::DFG::AvailabilityMap::prune): Deleted.
923         * dfg/DFGAvailabilityMap.h:
924         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
925         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
926         * ftl/FTLLowerDFGToLLVM.cpp:
927         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
928         * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
929         * tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.
930
931 2015-05-12  Gabor Loki  <loki@webkit.org>
932
933         Workaround for Cortex-A53 erratum 843419
934         https://bugs.webkit.org/show_bug.cgi?id=144680
935
936         Reviewed by Michael Saboff.
937
938         This patch is about to give simple workaround for Cortex-A53 erratum 843419.
939         It inserts nops after ADRP instruction to avoid wrong address accesses.
940
941         * assembler/ARM64Assembler.h:
942         (JSC::ARM64Assembler::adrp):
943         (JSC::ARM64Assembler::nopCortexA53Fix843419):
944
945 2015-05-11  Commit Queue  <commit-queue@webkit.org>
946
947         Unreviewed, rolling out r184009.
948         https://bugs.webkit.org/show_bug.cgi?id=144900
949
950         Caused crashes on inspector tests (Requested by ap on
951         #webkit).
952
953         Reverted changeset:
954
955         "MapDataImpl::add() shouldn't do the same hash lookup twice."
956         https://bugs.webkit.org/show_bug.cgi?id=144759
957         http://trac.webkit.org/changeset/184009
958
959 2015-05-11  Commit Queue  <commit-queue@webkit.org>
960
961         Unreviewed, rolling out r184123.
962         https://bugs.webkit.org/show_bug.cgi?id=144899
963
964         Seems to have introduced flaky crashes in many JS tests
965         (Requested by rniwa on #webkit).
966
967         Reverted changeset:
968
969         "REGRESSION(r180595): same-callee profiling no longer works"
970         https://bugs.webkit.org/show_bug.cgi?id=144787
971         http://trac.webkit.org/changeset/184123
972
973 2015-05-11  Brent Fulgham  <bfulgham@apple.com>
974
975         [Win] Move Windows build target to Windows 7 (or newer)
976         https://bugs.webkit.org/show_bug.cgi?id=144890
977         <rdar://problem/20707307>
978
979         Reviewed by Anders Carlsson.
980
981         Update linked SDK and minimal Windows level to be compatible with
982         Windows 7 or newer.
983
984         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
985         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
986         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
987         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
988         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
989         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
990         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
991         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
992         * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
993         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
994         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
995         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
996         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
997         * config.h:
998
999 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1000
1001         CPS rethreading phase's flush detector flushes way too many SetLocals
1002         https://bugs.webkit.org/show_bug.cgi?id=144819
1003
1004         Reviewed by Geoffrey Garen.
1005         
1006         After probably unrelated changes, this eventually caused some arguments elimination to stop
1007         working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
1008         a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
1009         meant to only affect the SetLocal itself.
1010         
1011         This is a speed-up on Octane/earley.
1012
1013         * dfg/DFGCPSRethreadingPhase.cpp:
1014         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
1015
1016 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1017
1018         gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
1019         https://bugs.webkit.org/show_bug.cgi?id=144854
1020
1021         Reviewed by Oliver Hunt.
1022         
1023         This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
1024         It used to be that Construct required less code, but that's not the case for now.
1025
1026         * ftl/FTLInlineCacheSize.cpp:
1027         (JSC::FTL::sizeOfCallForwardVarargs):
1028         (JSC::FTL::sizeOfConstructVarargs):
1029         (JSC::FTL::sizeOfConstructForwardVarargs):
1030
1031 2015-05-11  Ryosuke Niwa  <rniwa@webkit.org>
1032
1033         REGRESSION(r180595): same-callee profiling no longer works
1034         https://bugs.webkit.org/show_bug.cgi?id=144787
1035
1036         Reviewed by Michael Saboff.
1037
1038         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
1039         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
1040         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
1041
1042         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
1043         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
1044         our speculation that the callee is the same. To avoid recompiling the same code for different callee
1045         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
1046         LLint and baseline JIT when multiple callees are observed.
1047
1048         Tests: stress/create-this-with-callee-variants.js
1049
1050         * bytecode/BytecodeList.json: Increased the number of operands to 5.
1051         * bytecode/BytecodeUseDef.h:
1052         (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
1053         operands.
1054         * bytecode/CodeBlock.cpp:
1055         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
1056         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
1057         * bytecompiler/BytecodeGenerator.cpp:
1058         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
1059         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
1060         operand.
1061         * dfg/DFGByteCodeParser.cpp:
1062         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
1063         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
1064         * jit/JITOpcodes.cpp:
1065         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
1066         as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
1067         (JSC::JIT::emitSlow_op_create_this):
1068         * jit/JITOpcodes32_64.cpp:
1069         (JSC::JIT::emit_op_create_this): Ditto.
1070         (JSC::JIT::emitSlow_op_create_this):
1071         * llint/LowLevelInterpreter32_64.asm:
1072         (_llint_op_create_this): Ditto.
1073         * llint/LowLevelInterpreter64.asm:
1074         (_llint_op_create_this): Ditto.
1075         * runtime/CommonSlowPaths.cpp:
1076         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
1077         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
1078         * runtime/JSCell.h:
1079         (JSC::JSCell::seenMultipleCalleeObjects): Added.
1080         * runtime/WriteBarrier.h:
1081         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
1082         * tests/stress/create-this-with-callee-variants.js: Added.
1083
1084 2015-05-11  Andreas Kling  <akling@apple.com>
1085
1086         PropertyNameArray should use a Vector when there are few entries.
1087         <https://webkit.org/b/144874>
1088
1089         Reviewed by Geoffrey Garen.
1090
1091         Bring back an optimization that was lost in the for-in refactoring.
1092         PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
1093         enough (20) entries to justify converting to a HashSet for contains().
1094
1095         Also inlined the code while we're here, since it has so few clients and
1096         the call overhead adds up.
1097
1098         ~5% progression on Kraken/json-stringify-tinderbox.
1099
1100         * runtime/PropertyNameArray.cpp: Removed.
1101         * runtime/PropertyNameArray.h:
1102         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1103         (JSC::PropertyNameArray::add):
1104         (JSC::PropertyNameArray::addKnownUnique):
1105
1106 2015-05-11  Matt Baker  <mattbaker@apple.com>
1107
1108         Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
1109         https://bugs.webkit.org/show_bug.cgi?id=144808
1110
1111         Reviewed by Darin Adler.
1112
1113         Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
1114         The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
1115
1116         * profiler/Profile.cpp:
1117         (JSC::Profile::create):
1118         (JSC::Profile::Profile):
1119         * profiler/Profile.h:
1120         * profiler/ProfileGenerator.cpp:
1121         (JSC::ProfileGenerator::ProfileGenerator):
1122         (JSC::AddParentForConsoleStartFunctor::operator()):
1123
1124 2015-05-11  Basile Clement  <basile_clement@apple.com>
1125
1126         Unreviewed, remove unintended change.
1127
1128         * dfg/DFGAbstractInterpreterInlines.h:
1129         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1130
1131 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1132
1133         Make it easy to enable eager/non-concurrent JIT compilation
1134         https://bugs.webkit.org/show_bug.cgi?id=144877
1135
1136         Reviewed by Michael Saboff.
1137
1138         * runtime/Options.cpp:
1139         (JSC::recomputeDependentOptions):
1140         * runtime/Options.h:
1141
1142 2015-05-10  Filip Pizlo  <fpizlo@apple.com>
1143
1144         We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
1145         https://bugs.webkit.org/show_bug.cgi?id=144851
1146
1147         Reviewed by Michael Saboff.
1148         
1149         LoadVarargs loads arguments from some object and puts them on the stack. The region of
1150         stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
1151         shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
1152         something that uses more stack than the LoadVarargs wanted to.
1153         
1154         This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
1155         promoter. This is an important promotion rule for performance, and in cases where we are
1156         compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
1157         the phantom arguments array that this phase sees. The LoadVarargs limit is based on
1158         profiling and the phantom arguments array is a proof; in most cases the profiling is more
1159         conservative.
1160         
1161         But, you could write some crazy code where the statically obvious arguments array value is
1162         bigger than what the profiling would have told you. When this happens, this promotion
1163         effectively removes a bounds check. This either results in us clobbering a bunch of stack,
1164         or it means that we never initialize a region of the stack that a later operation will read
1165         (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
1166         unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
1167         the original LoadVarargs limit).
1168         
1169         * dfg/DFGArgumentsEliminationPhase.cpp:
1170         * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
1171         (foo):
1172         (bar):
1173         (baz):
1174         * tests/stress/load-varargs-elimination-bounds-check.js: Added.
1175         (foo):
1176         (bar):
1177         (baz):
1178
1179 2015-05-11  Andreas Kling  <akling@apple.com>
1180
1181         JSON.stringify shouldn't use generic get() to access Array.length
1182         <https://webkit.org/b/144847>
1183
1184         Reviewed by Geoffrey Garen.
1185
1186         If the value being serialized is a JSArray object, we can downcast and call its
1187         length() directly instead of doing a generic property lookup.
1188
1189         0.5% progression on Kraken/json-stringify-tinderbox.
1190
1191         * runtime/JSONObject.cpp:
1192         (JSC::Stringifier::Holder::appendNextProperty):
1193
1194 2015-05-10  Andreas Kling  <akling@apple.com>
1195
1196         Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
1197
1198         Follow up to r184050 suggested by Darin.
1199
1200         * runtime/PropertyNameArray.h:
1201
1202 2015-05-10  Andreas Kling  <akling@apple.com>
1203
1204         Remove unused things from PropertyNameArray.
1205         <https://webkit.org/b/144834>
1206
1207         Reviewed by Filip Pizlo.
1208
1209         PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
1210         was refactored and optimized last year. Then more refactoring happened and this class
1211         doesn't need to ring and toot anymore.
1212
1213         The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
1214         actually using it for anything and we were just wasting time creating these.
1215
1216         Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
1217
1218         * runtime/JSObject.cpp:
1219         (JSC::JSObject::getPropertyNames):
1220         * runtime/JSPropertyNameEnumerator.cpp:
1221         (JSC::JSPropertyNameEnumerator::create):
1222         (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
1223         * runtime/JSPropertyNameEnumerator.h:
1224         * runtime/PropertyNameArray.cpp:
1225         (JSC::PropertyNameArray::add):
1226         (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
1227         * runtime/PropertyNameArray.h:
1228         (JSC::PropertyNameArray::PropertyNameArray):
1229         (JSC::PropertyNameArray::add):
1230         (JSC::PropertyNameArray::addKnownUnique):
1231         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1232         (JSC::RefCountedIdentifierSet::contains): Deleted.
1233         (JSC::RefCountedIdentifierSet::size): Deleted.
1234         (JSC::RefCountedIdentifierSet::add): Deleted.
1235         (JSC::PropertyNameArray::identifierSet): Deleted.
1236         (JSC::PropertyNameArray::numCacheableSlots): Deleted.
1237         (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
1238         (JSC::PropertyNameArray::setBaseObject): Deleted.
1239         (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
1240
1241 2015-05-09  Yoav Weiss  <yoav@yoav.ws>
1242
1243         Remove the PICTURE_SIZES build flag
1244         https://bugs.webkit.org/show_bug.cgi?id=144679
1245
1246         Reviewed by Benjamin Poulain.
1247
1248         Removed the PICTURE_SIZES build time flag.
1249
1250         * Configurations/FeatureDefines.xcconfig:
1251
1252 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1253
1254         Extend the SaneChain optimization to Contiguous arrays
1255         https://bugs.webkit.org/show_bug.cgi?id=144664
1256
1257         Reviewed by Mark Lam.
1258         
1259         Previously if you loaded from a hole, you'd either have to take slow path for the array
1260         load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
1261         gathered the necessary profiling yet). But that's unnecessary if we know that the
1262         prototype chain is sane - i.e. has no indexed properties. Then we can just return
1263         Undefined for the hole.
1264         
1265         Making this change requires setting more watchpoints on the array prototype chain. But
1266         that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
1267         itself up lazily. This means that this increased the number of recompilations we'd get
1268         due to the array prototype chain being built up.
1269         
1270         So, this change also removes the laziness and static tables from ArrayPrototype.
1271         
1272         But to make that change, I also had to add a helper for eagerly building up a prototype
1273         that has builtin functions.
1274
1275         * CMakeLists.txt:
1276         * DerivedSources.make:
1277         * dfg/DFGArrayMode.h:
1278         * dfg/DFGFixupPhase.cpp:
1279         (JSC::DFG::FixupPhase::fixupNode):
1280         * dfg/DFGSpeculativeJIT32_64.cpp:
1281         (JSC::DFG::SpeculativeJIT::compile):
1282         * dfg/DFGSpeculativeJIT64.cpp:
1283         (JSC::DFG::SpeculativeJIT::compile):
1284         * ftl/FTLLowerDFGToLLVM.cpp:
1285         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
1286         * runtime/ArrayPrototype.cpp:
1287         (JSC::ArrayPrototype::finishCreation):
1288         (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
1289         * runtime/ArrayPrototype.h:
1290         * runtime/JSObject.h:
1291
1292 2015-05-08  Michael Saboff  <msaboff@apple.com>
1293
1294         Creating a large MarkedBlock sometimes results in more than one cell in the block
1295         https://bugs.webkit.org/show_bug.cgi?id=144815
1296
1297         Reviewed by Mark Lam.
1298
1299         Large MarkedBlocks should have one and only one cell.  Changed the calculation of
1300         m_endAtom for large blocks to use the location of the first cell + 1.  This
1301         assures that large blocks only have one cell.
1302
1303         * heap/MarkedBlock.cpp:
1304         (JSC::MarkedBlock::MarkedBlock):
1305
1306 2015-05-08  Oliver Hunt  <oliver@apple.com>
1307
1308         MapDataImpl::add() shouldn't do the same hash lookup twice.
1309         https://bugs.webkit.org/show_bug.cgi?id=144759
1310
1311         Reviewed by Gavin Barraclough.
1312
1313         We don't actually need to do a double lookup here, all we need to
1314         do is update the index to point to the correct m_size.
1315
1316         * runtime/MapDataInlines.h:
1317         (JSC::JSIterator>::add):
1318
1319 2015-05-08  Andreas Kling  <akling@apple.com>
1320
1321         Micro-optimize JSON serialization of string primitives.
1322         <https://webkit.org/b/144800>
1323
1324         Reviewed by Sam Weinig.
1325
1326         Don't use the out-of-line JSValue::getString() to grab at string primitives
1327         in serialization. Just check if it's a JSString and then downcast to grab at
1328         the WTF::String inside.
1329
1330         2% progression on Kraken/json-stringify-tinderbox.
1331
1332         * runtime/JSONObject.cpp:
1333         (JSC::Stringifier::appendStringifiedValue):
1334
1335 2015-05-08  Andreas Kling  <akling@apple.com>
1336
1337         Optimize serialization of quoted JSON strings.
1338         <https://webkit.org/b/144754>
1339
1340         Reviewed by Darin Adler.
1341
1342         Optimized the serialization of quoted strings into JSON by moving the logic into
1343         StringBuilder so it can make smarter decisions about buffering.
1344
1345         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
1346
1347         * bytecompiler/NodesCodegen.cpp:
1348         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
1349
1350         * runtime/JSONObject.h:
1351         * runtime/JSONObject.cpp:
1352         (JSC::Stringifier::Holder::appendNextProperty):
1353         (JSC::appendStringToStringBuilder): Deleted.
1354         (JSC::appendQuotedJSONStringToBuilder): Deleted.
1355         (JSC::Stringifier::appendQuotedString): Deleted.
1356         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
1357         to StringBuilder and call that from here.
1358
1359 2015-05-07  Commit Queue  <commit-queue@webkit.org>
1360
1361         Unreviewed, rolling out r183961.
1362         https://bugs.webkit.org/show_bug.cgi?id=144784
1363
1364         Broke js/dom/JSON-stringify.html (Requested by kling on
1365         #webkit).
1366
1367         Reverted changeset:
1368
1369         "Optimize serialization of quoted JSON strings."
1370         https://bugs.webkit.org/show_bug.cgi?id=144754
1371         http://trac.webkit.org/changeset/183961
1372
1373 2015-05-07  Filip Pizlo  <fpizlo@apple.com>
1374
1375         GC has trouble with pathologically large array allocations
1376         https://bugs.webkit.org/show_bug.cgi?id=144609
1377
1378         Reviewed by Geoffrey Garen.
1379
1380         The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
1381         after pinning them), and would skip the accounting. The GC calculates the size of the heap
1382         in tandem with the scan to save time, and that accounting was part of how the GC would
1383         know how big the heap was. The GC would then think that oversize copied blocks use no
1384         memory, and would then mess up its scheduling of the next GC.
1385         
1386         Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
1387         size by summing the size from the last collection and the size by walking the eden heap.
1388         But this breaks when we eagerly delete objects that the last collection touched. We can do
1389         that in one corner case: copied block reallocation. The old block will be deleted from old
1390         space during the realloc and a new block will be allocated in new space. In order for the
1391         GC to know that the size of old space actually shrank, we need a field to tell us how much
1392         such shrinkage could occur. Since this is a very dirty corner case and it only works for
1393         very particular reasons arising from the special properties of copied space (single owner,
1394         and the realloc is used in places where the compiler already knows that it cannot register
1395         allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
1396         devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
1397         
1398         To test this, I needed to add an Option to force a particular RAM size in the GC. This
1399         allows us to write tests that assert that the GC heap size is some value X, without
1400         worrying about machine-to-machine variations due to GC heuristics changing based on RAM
1401         size.
1402
1403         * heap/CopiedSpace.cpp:
1404         (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
1405         (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
1406         * heap/CopiedSpace.h:
1407         (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
1408         * heap/Heap.cpp:
1409         (JSC::Heap::Heap): Allow the user to force the RAM size.
1410         (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
1411         * heap/SlotVisitorInlines.h:
1412         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
1413         * jsc.cpp: Add size measuring hooks to write the largeish test.
1414         (GlobalObject::finishCreation):
1415         (functionGCAndSweep):
1416         (functionFullGC):
1417         (functionEdenGC):
1418         (functionHeapSize):
1419         * runtime/Options.h:
1420         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
1421         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
1422         (foo):
1423         (test):
1424
1425 2015-05-07  Saam Barati  <saambarati1@gmail.com>
1426
1427         Global functions should be initialized as JSFunctions in byte code
1428         https://bugs.webkit.org/show_bug.cgi?id=144178
1429
1430         Reviewed by Geoffrey Garen.
1431
1432         This patch makes the initialization of global functions more explicit by
1433         moving initialization into bytecode. It also prepares JSC for having ES6
1434         style lexical scoping because initializing global functions in bytecode
1435         easily allows global functions to be initialized with the proper scope that
1436         will have access to global lexical variables. Global lexical variables
1437         should be visible to global functions but don't live on the global object.
1438
1439         * bytecode/UnlinkedCodeBlock.cpp:
1440         (JSC::UnlinkedProgramCodeBlock::visitChildren):
1441         * bytecode/UnlinkedCodeBlock.h:
1442         * bytecompiler/BytecodeGenerator.cpp:
1443         (JSC::BytecodeGenerator::generate):
1444         (JSC::BytecodeGenerator::BytecodeGenerator):
1445         * bytecompiler/BytecodeGenerator.h:
1446         * runtime/Executable.cpp:
1447         (JSC::ProgramExecutable::initializeGlobalProperties):
1448         * runtime/JSGlobalObject.cpp:
1449         (JSC::JSGlobalObject::addGlobalVar):
1450         (JSC::JSGlobalObject::addFunction):
1451         * runtime/JSGlobalObject.h:
1452
1453 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1454
1455         Fix the x86 32bits build
1456
1457         * assembler/X86Assembler.h:
1458
1459 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1460
1461         [JSC] Add basic DFG/FTL support for Math.round
1462         https://bugs.webkit.org/show_bug.cgi?id=144725
1463
1464         Reviewed by Filip Pizlo.
1465
1466         This patch adds two optimizations targeting Math.round():
1467         -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
1468         -Change the MacroAssembler to be stricter on how we fail to convert a double
1469          to ingeter. Previously, any number valued zero would fail, now we only
1470          fail for -0.
1471
1472         Since ArithRound speculate it produces int32, the MacroAssembler assembler
1473         part became necessary because zero is a pretty common output of Math.round()
1474         and we would OSR exit a lot (and eventually recompile for doubles).
1475
1476         The implementation itself of the inline Math.round() is exactly the same
1477         as the C function that exists for Math.round(). We can very likely do better
1478         but it is a good start known to be valid and inlining alone alread provides
1479         significant speedups.
1480
1481         * assembler/X86Assembler.h:
1482         (JSC::X86Assembler::movmskpd_rr):
1483         * assembler/MacroAssemblerX86Common.h:
1484         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
1485         When we have a zero, get the sign bit out of the double and check if is one.
1486
1487         I'll look into doing the same improvement for ARM.
1488
1489         * bytecode/SpeculatedType.cpp:
1490         (JSC::typeOfDoubleRounding):
1491         (JSC::typeOfDoubleFRound): Deleted.
1492         * bytecode/SpeculatedType.h:
1493         * dfg/DFGAbstractInterpreterInlines.h:
1494         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1495         * dfg/DFGByteCodeParser.cpp:
1496         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1497         * dfg/DFGClobberize.h:
1498         (JSC::DFG::clobberize):
1499         * dfg/DFGDoesGC.cpp:
1500         (JSC::DFG::doesGC):
1501         * dfg/DFGFixupPhase.cpp:
1502         (JSC::DFG::FixupPhase::fixupNode):
1503         * dfg/DFGGraph.h:
1504         (JSC::DFG::Graph::roundShouldSpeculateInt32):
1505         (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
1506         * dfg/DFGNode.h:
1507         (JSC::DFG::Node::arithNodeFlags):
1508         (JSC::DFG::Node::hasHeapPrediction):
1509         (JSC::DFG::Node::hasArithMode):
1510         * dfg/DFGNodeType.h:
1511         * dfg/DFGPredictionPropagationPhase.cpp:
1512         (JSC::DFG::PredictionPropagationPhase::propagate):
1513         * dfg/DFGSafeToExecute.h:
1514         (JSC::DFG::safeToExecute):
1515         * dfg/DFGSpeculativeJIT.cpp:
1516         (JSC::DFG::SpeculativeJIT::compileArithRound):
1517         * dfg/DFGSpeculativeJIT.h:
1518         * dfg/DFGSpeculativeJIT32_64.cpp:
1519         (JSC::DFG::SpeculativeJIT::compile):
1520         * dfg/DFGSpeculativeJIT64.cpp:
1521         (JSC::DFG::SpeculativeJIT::compile):
1522         * ftl/FTLCapabilities.cpp:
1523         (JSC::FTL::canCompile):
1524         * ftl/FTLIntrinsicRepository.h:
1525         * ftl/FTLLowerDFGToLLVM.cpp:
1526         (JSC::FTL::LowerDFGToLLVM::compileNode):
1527         (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
1528         (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
1529         (JSC::FTL::LowerDFGToLLVM::compileArithRound):
1530         * ftl/FTLOutput.h:
1531         (JSC::FTL::Output::ceil64):
1532         * jit/ThunkGenerators.cpp:
1533         * runtime/MathCommon.cpp:
1534         * runtime/MathCommon.h:
1535         * runtime/MathObject.cpp:
1536         (JSC::mathProtoFuncRound):
1537         * tests/stress/math-round-basics.js: Added.
1538         (mathRoundOnIntegers):
1539         (mathRoundOnDoubles):
1540         (mathRoundOnBooleans):
1541         (uselessMathRound):
1542         (mathRoundWithOverflow):
1543         (mathRoundConsumedAsDouble):
1544         (mathRoundDoesNotCareAboutMinusZero):
1545         (mathRoundNoArguments):
1546         (mathRoundTooManyArguments):
1547         (testMathRoundOnConstants):
1548         (mathRoundStructTransition):
1549         (Math.round):
1550
1551 2015-05-07  Saam Barati  <saambarati1@gmail.com>
1552
1553         exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
1554         https://bugs.webkit.org/show_bug.cgi?id=144753
1555
1556         Reviewed by Mark Lam.
1557
1558         This allows the BytecodeGenerator to freely emit startup code that "may"
1559         throw exceptions without worrying that this startup code will trigger
1560         the exceptionFuzz exception. The exceptionFuzz counter will only begin
1561         ticking when the 'enableExceptionFuzz' function is explicitly called in 
1562         the exceptionFuzz tests.
1563
1564         * jsc.cpp:
1565         (GlobalObject::finishCreation):
1566         (functionEnableExceptionFuzz):
1567         * tests/exceptionFuzz/3d-cube.js:
1568         * tests/exceptionFuzz/date-format-xparb.js:
1569         * tests/exceptionFuzz/earley-boyer.js:
1570
1571 2015-05-07  Andreas Kling  <akling@apple.com>
1572
1573         Optimize serialization of quoted JSON strings.
1574         <https://webkit.org/b/144754>
1575
1576         Reviewed by Darin Adler.
1577
1578         Optimized the serialization of quoted strings into JSON by moving the logic into
1579         StringBuilder so it can make smarter decisions about buffering.
1580
1581         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
1582
1583         * bytecompiler/NodesCodegen.cpp:
1584         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
1585
1586         * runtime/JSONObject.h:
1587         * runtime/JSONObject.cpp:
1588         (JSC::Stringifier::Holder::appendNextProperty):
1589         (JSC::appendStringToStringBuilder): Deleted.
1590         (JSC::appendQuotedJSONStringToBuilder): Deleted.
1591         (JSC::Stringifier::appendQuotedString): Deleted.
1592         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
1593         to StringBuilder and call that from here.
1594
1595 2015-05-07  Yusuke Suzuki  <utatane.tea@gmail.com>
1596
1597         FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
1598         https://bugs.webkit.org/show_bug.cgi?id=144678
1599
1600         Reviewed by Geoffrey Garen.
1601
1602         Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
1603         But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
1604
1605         function t() { var ok = {null: function () { } }; ok[ok = null](); }
1606         t();  // Should not throw error.
1607
1608         This patch takes care about `subscriptHasAssignment`.
1609         By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
1610         it correctly moves the LHS value to a temporary register.
1611
1612         * bytecompiler/NodesCodegen.cpp:
1613         (JSC::FunctionCallBracketNode::emitBytecode):
1614         * parser/ASTBuilder.h:
1615         (JSC::ASTBuilder::makeFunctionCallNode):
1616         * parser/NodeConstructors.h:
1617         (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
1618         * parser/Nodes.h:
1619         * tests/stress/assignment-in-function-call-bracket-node.js: Added.
1620         (shouldBe):
1621         (shouldBe.):
1622
1623 2015-05-07  Basile Clement  <basile_clement@apple.com>
1624
1625         Unreviewed, add missing braces on a single-line if that got expanded in r183939
1626
1627         * ftl/FTLLowerDFGToLLVM.cpp:
1628         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1629
1630 2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>
1631
1632         Revert "Introducing the Platform Abstraction Layer (PAL)"
1633         https://bugs.webkit.org/show_bug.cgi?id=144751
1634
1635         Unreviewed.
1636
1637         PAL should be a new target inside WebCore, rather than a top-level folder.
1638
1639         * Configurations/FeatureDefines.xcconfig: Updated
1640
1641 2015-05-07  Basile Clement  <basile_clement@apple.com>
1642
1643         Dumping OSR ExitValue should expand materializations only once
1644         https://bugs.webkit.org/show_bug.cgi?id=144694
1645
1646         Reviewed by Filip Pizlo.
1647
1648         Currently, dumping OSR exit values will print the full materialization
1649         information each time it is encountered. We change it to print only a
1650         brief description (only the materialization's address), and print the
1651         whole set of materializations later on.
1652
1653         This makes the dump less confusing (less likely to think that two
1654         instances of the same materialization are different), and will be a
1655         necessary change if/when we support materialization cycles.
1656
1657         * ftl/FTLCompile.cpp:
1658         (JSC::FTL::mmAllocateDataSection):
1659         * ftl/FTLExitValue.cpp:
1660         (JSC::FTL::ExitValue::dumpInContext):
1661         * ftl/FTLLowerDFGToLLVM.cpp:
1662         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1663
1664 2015-05-07  Andreas Kling  <akling@apple.com>
1665
1666         Worker threads leak WeakBlocks (as seen on leaks bot)
1667         <https://webkit.org/b/144721>
1668         <rdar://problem/20848288>
1669
1670         Reviewed by Darin Adler.
1671
1672         Nuke any remaining empty WeakBlocks when the Heap is being torn down.
1673         Trying to peek into these blocks after the VM is dead would be a bug anyway.
1674
1675         This fixes a ~750 KB leak seen on the leaks bot.
1676
1677         * heap/Heap.cpp:
1678         (JSC::Heap::~Heap):
1679
1680 2015-05-05  Geoffrey Garen  <ggaren@apple.com>
1681
1682         Don't branch when accessing the callee
1683         https://bugs.webkit.org/show_bug.cgi?id=144645
1684
1685         Reviewed by Michael Saboff.
1686
1687         The branch was added in <http://trac.webkit.org/changeset/81040> without
1688         explanation.
1689
1690         kling found it to be a performance problem. See <https://webkit.org/b/144586>.
1691
1692         Our theory of access to Registers is that it's up to the client to access
1693         them in the right way. So, let's do that.
1694
1695         * interpreter/CallFrame.h:
1696         (JSC::ExecState::callee):
1697         (JSC::ExecState::setCallee): Call the field object instead of function
1698         because nothing guarantees that it's a function.
1699         * interpreter/ProtoCallFrame.h:
1700         (JSC::ProtoCallFrame::callee):
1701         (JSC::ProtoCallFrame::setCallee):
1702         * interpreter/Register.h:
1703         * runtime/JSObject.h:
1704         (JSC::Register::object): Just do a cast like our other accessors do.
1705         (JSC::Register::operator=):
1706         (JSC::Register::function): Deleted.
1707         (JSC::Register::withCallee): Deleted.
1708
1709 2015-05-07  Dan Bernstein  <mitz@apple.com>
1710
1711         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
1712         https://bugs.webkit.org/show_bug.cgi?id=144727
1713
1714         Reviewed by Darin Adler.
1715
1716         * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
1717         INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
1718
1719 2015-05-07  Andreas Kling  <akling@apple.com>
1720
1721         Special-case Int32 values in JSON.stringify().
1722         <https://webkit.org/b/144731>
1723
1724         Reviewed by Michael Saboff.
1725
1726         Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
1727         simple integers through the full-blown dtoa() machinery.
1728
1729         ~50% speedup on Kraken/json-stringify-tinderbox.
1730
1731         * runtime/JSONObject.cpp:
1732         (JSC::Stringifier::appendStringifiedValue):
1733
1734 2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>
1735
1736         ToT WebKit crashes while loading ES6 compatibility table
1737         https://bugs.webkit.org/show_bug.cgi?id=144726
1738
1739         Reviewed by Filip Pizlo.
1740
1741         The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
1742
1743         Always build the identifier here as it could be a method name.
1744
1745         * parser/Parser.cpp:
1746         (JSC::Parser<LexerType>::parseClass):
1747
1748 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1749
1750         Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
1751         https://bugs.webkit.org/show_bug.cgi?id=144665
1752
1753         Reviewed by Michael Saboff.
1754         
1755         This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
1756         extending SaneChain to all indexing shapes.
1757
1758         * dfg/DFGFixupPhase.cpp:
1759         (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
1760         (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
1761         * dfg/DFGSpeculativeJIT.cpp:
1762         (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
1763         * dfg/DFGWatchpointCollectionPhase.cpp:
1764         (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
1765         (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
1766         * ftl/FTLLowerDFGToLLVM.cpp:
1767         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
1768
1769 2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>
1770
1771         Introducing the Platform Abstraction Layer (PAL)
1772         https://bugs.webkit.org/show_bug.cgi?id=143358
1773
1774         Reviewed by Simon Fraser.
1775
1776         * Configurations/FeatureDefines.xcconfig: Updated
1777
1778 2015-05-06  Andreas Kling  <akling@apple.com>
1779
1780         Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
1781         <https://webkit.org/b/144676>
1782
1783         Reviewed by Darin Adler.
1784
1785         We were creating a new String for every number JSValue passing through the JSON stringifier.
1786         These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
1787         Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
1788         for the conversion instead.
1789
1790         13% progression on Kraken/json-stringify-tinderbox.
1791
1792         * runtime/JSONObject.cpp:
1793         (JSC::Stringifier::appendStringifiedValue):
1794
1795 2015-05-06  Commit Queue  <commit-queue@webkit.org>
1796
1797         Unreviewed, rolling out r183847.
1798         https://bugs.webkit.org/show_bug.cgi?id=144691
1799
1800         Caused many assertion failures (Requested by ap on #webkit).
1801
1802         Reverted changeset:
1803
1804         "GC has trouble with pathologically large array allocations"
1805         https://bugs.webkit.org/show_bug.cgi?id=144609
1806         http://trac.webkit.org/changeset/183847
1807
1808 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1809
1810         PutGlobalVar shouldn't have an unconditional store barrier
1811         https://bugs.webkit.org/show_bug.cgi?id=133104
1812
1813         Reviewed by Benjamin Poulain.
1814         
1815         We don't need a store barrier on PutGlobalVar if the value being stored can be
1816         speculated to not be a cell.
1817
1818         * dfg/DFGFixupPhase.cpp:
1819         (JSC::DFG::FixupPhase::fixupNode):
1820
1821 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1822
1823         CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
1824         https://bugs.webkit.org/show_bug.cgi?id=144667
1825
1826         Reviewed by Andreas Kling.
1827         
1828         We are now calling this method for oversize blocks. It had an assertion that indirectly
1829         implied that the block is not oversize, because it was claiming that the number of live
1830         bytes should be smaller than the non-oversize-block size.
1831
1832         * heap/CopiedBlockInlines.h:
1833         (JSC::CopiedBlock::reportLiveBytes):
1834
1835 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1836
1837         GC has trouble with pathologically large array allocations
1838         https://bugs.webkit.org/show_bug.cgi?id=144609
1839
1840         Reviewed by Mark Lam.
1841
1842         * heap/Heap.cpp:
1843         (JSC::Heap::updateObjectCounts): Make this code less confusing.
1844         * heap/SlotVisitorInlines.h:
1845         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
1846         * jsc.cpp: Add size measuring hooks to write the largeish test.
1847         (GlobalObject::finishCreation):
1848         (functionGCAndSweep):
1849         (functionFullGC):
1850         (functionEdenGC):
1851         (functionHeapSize):
1852         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
1853         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
1854         (foo):
1855         (test):
1856
1857 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1858
1859         FTL SwitchString slow case creates duplicate switch cases
1860         https://bugs.webkit.org/show_bug.cgi?id=144634
1861
1862         Reviewed by Geoffrey Garen.
1863         
1864         The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
1865         added mostly-debug-only asserts to catch such issues earlier.
1866
1867         * bytecode/CallVariant.cpp:
1868         (JSC::variantListWithVariant): Assertion to prevent similar bugs.
1869         * ftl/FTLLowerDFGToLLVM.cpp:
1870         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
1871         (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
1872         * jit/BinarySwitch.cpp:
1873         (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
1874         * jit/Repatch.cpp:
1875         (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
1876         * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
1877         (foo):
1878         (cat):
1879
1880 2015-05-05  Basile Clement  <basile_clement@apple.com>
1881
1882         Fix debug builds after r183812
1883         https://bugs.webkit.org/show_bug.cgi?id=144300
1884
1885         Rubber stamped by Andreas Kling and Filip Pizlo.
1886
1887         hasObjectMaterializationData() didn't treat MaterializeCreateActivation
1888         as having materialization data, which was causing an assertion failure when
1889         sinking CreateActivations on debug builds.
1890
1891         * dfg/DFGNode.h:
1892         (JSC::DFG::Node::hasObjectMaterializationData):
1893
1894 2015-05-04  Basile Clement  <basile_clement@apple.com>
1895
1896         Allow CreateActivation sinking
1897         https://bugs.webkit.org/show_bug.cgi?id=144300
1898
1899         Reviewed by Filip Pizlo.
1900
1901         This pursues the work started in
1902         https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
1903         allocations we are able to sink by allowing sinking of CreateActivation
1904         node.
1905
1906         This is achieved by following closely the way NewObject is currently
1907         sunk: we add a new PhantomCreateActivation node to record the initial
1908         position of the CreateActivation node, new ClosureVarPLoc promoted heap
1909         locations to keep track of the variables put in the activation, and a
1910         new MaterializeCreateActivation node to allocate and populate the sunk
1911         activation.
1912
1913         * dfg/DFGAbstractInterpreterInlines.h:
1914         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1915         * dfg/DFGClobberize.h:
1916         (JSC::DFG::clobberize):
1917         * dfg/DFGDoesGC.cpp:
1918         (JSC::DFG::doesGC):
1919         * dfg/DFGFixupPhase.cpp:
1920         (JSC::DFG::FixupPhase::fixupNode):
1921         * dfg/DFGNode.cpp:
1922         (JSC::DFG::Node::convertToPutClosureVarHint):
1923         * dfg/DFGNode.h:
1924         (JSC::DFG::Node::convertToPhantomCreateActivation):
1925         (JSC::DFG::Node::isActivationAllocation):
1926         (JSC::DFG::Node::isPhantomActivationAllocation):
1927         (JSC::DFG::Node::isPhantomAllocation):
1928         * dfg/DFGNodeType.h:
1929         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1930         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1931         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1932         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
1933         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
1934         * dfg/DFGPredictionPropagationPhase.cpp:
1935         (JSC::DFG::PredictionPropagationPhase::propagate):
1936         * dfg/DFGPromotedHeapLocation.cpp:
1937         (WTF::printInternal):
1938         * dfg/DFGPromotedHeapLocation.h:
1939         * dfg/DFGSafeToExecute.h:
1940         (JSC::DFG::safeToExecute):
1941         * dfg/DFGSpeculativeJIT32_64.cpp:
1942         (JSC::DFG::SpeculativeJIT::compile):
1943         * dfg/DFGSpeculativeJIT64.cpp:
1944         (JSC::DFG::SpeculativeJIT::compile):
1945         * dfg/DFGValidate.cpp:
1946         (JSC::DFG::Validate::validateCPS):
1947         * ftl/FTLCapabilities.cpp:
1948         (JSC::FTL::canCompile):
1949         * ftl/FTLLowerDFGToLLVM.cpp:
1950         (JSC::FTL::LowerDFGToLLVM::compileNode):
1951         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
1952         * ftl/FTLOperations.cpp:
1953         (JSC::FTL::operationMaterializeObjectInOSR):
1954         * tests/stress/activation-sink-osrexit.js: Added.
1955         (bar):
1956         (foo.set result):
1957         * tests/stress/activation-sink.js: Added.
1958         (bar):
1959
1960 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
1961
1962         Unreviewed, fix stale comment.
1963
1964         * tests/mozilla/js1_5/Array/regress-101964.js:
1965
1966 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
1967
1968         Large array shouldn't be slow
1969         https://bugs.webkit.org/show_bug.cgi?id=144617
1970
1971         Rubber stamped by Mark Lam.
1972
1973         * tests/mozilla/js1_5/Array/regress-101964.js: 500ms isn't enough in debug mode. We don't care how long this takes so long as we run it to completion. I've raised the limit much higher.
1974
1975 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
1976
1977         Large array shouldn't be slow
1978         https://bugs.webkit.org/show_bug.cgi?id=144617
1979
1980         Rubber stamped by Mark Lam.
1981
1982         * tests/mozilla/js1_5/Array/regress-101964.js: Mozilla may have cared about this being fast a decade ago (or more), but we don't care. We've consistently found that an array implementation that punishes this case to get speed on common-case array accesses is better. This should fix some test failures on the bots.
1983
1984 2015-05-04  Commit Queue  <commit-queue@webkit.org>
1985
1986         Unreviewed, rolling out r183789.
1987         https://bugs.webkit.org/show_bug.cgi?id=144620
1988
1989         Causing flakiness on exceptionFuzz tests locally on 32-bit
1990         build (Requested by saamyjoon on #webkit).
1991
1992         Reverted changeset:
1993
1994         "Global functions should be initialized as JSFunctions in byte
1995         code"
1996         https://bugs.webkit.org/show_bug.cgi?id=144178
1997         http://trac.webkit.org/changeset/183789
1998
1999 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2000
2001         Global functions should be initialized as JSFunctions in byte code
2002         https://bugs.webkit.org/show_bug.cgi?id=144178
2003
2004         Reviewed by Geoffrey Garen.
2005
2006         This patch makes the initialization of global functions more explicit by
2007         moving initialization into bytecode. It also prepares JSC for having ES6
2008         style lexical scoping because initializing global functions in bytecode
2009         easily allows global functions to be initialized with the proper scope that
2010         will have access to global lexical variables. Global lexical variables
2011         should be visible to global functions but don't live on the global object.
2012
2013         * bytecode/UnlinkedCodeBlock.cpp:
2014         (JSC::UnlinkedProgramCodeBlock::visitChildren):
2015         * bytecode/UnlinkedCodeBlock.h:
2016         * bytecompiler/BytecodeGenerator.cpp:
2017         (JSC::BytecodeGenerator::generate):
2018         (JSC::BytecodeGenerator::BytecodeGenerator):
2019         * bytecompiler/BytecodeGenerator.h:
2020         * runtime/Executable.cpp:
2021         (JSC::ProgramExecutable::initializeGlobalProperties):
2022         * runtime/JSGlobalObject.cpp:
2023         (JSC::JSGlobalObject::addGlobalVar):
2024         (JSC::JSGlobalObject::addFunction):
2025         * runtime/JSGlobalObject.h:
2026
2027 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2028
2029         Large array shouldn't be slow
2030         https://bugs.webkit.org/show_bug.cgi?id=144617
2031
2032         Reviewed by Geoffrey Garen.
2033         
2034         Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
2035         you're already using ArrayStorage mode, from the minimul array length required to use
2036         ArrayStorage in a new Array(length) allocation.
2037         
2038         Lift the array allocation length threshold to something very high. If this works, we'll
2039         probably remove that threshold entirely.
2040         
2041         This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
2042         JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
2043         for now.
2044
2045         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2046         * dfg/DFGSpeculativeJIT32_64.cpp:
2047         (JSC::DFG::SpeculativeJIT::compile):
2048         * dfg/DFGSpeculativeJIT64.cpp:
2049         (JSC::DFG::SpeculativeJIT::compile):
2050         * ftl/FTLLowerDFGToLLVM.cpp:
2051         (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
2052         * runtime/ArrayConventions.h:
2053         * runtime/JSArray.h:
2054         (JSC::JSArray::create):
2055         * runtime/JSGlobalObject.h:
2056         (JSC::constructEmptyArray):
2057         * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
2058
2059 2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2060
2061         Add backed intrinsics to private functions exposed with private symbols in global object
2062         https://bugs.webkit.org/show_bug.cgi?id=144545
2063
2064         Reviewed by Darin Adler.
2065
2066         Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
2067         This patch adds intrinsic to private functions exposed with private symbols in global object,
2068         @floor and @abs.
2069
2070         * runtime/JSGlobalObject.cpp:
2071         (JSC::JSGlobalObject::init):
2072         * runtime/JSGlobalObjectFunctions.cpp:
2073         (JSC::globalPrivateFuncAbs): Deleted.
2074         (JSC::globalPrivateFuncFloor): Deleted.
2075         * runtime/MathObject.cpp:
2076         * runtime/MathObject.h:
2077         * tests/stress/array-from-abs-and-floor.js: Added.
2078         (target1):
2079         (target2):
2080         (target3):
2081
2082 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2083
2084         [cmake] ARM related build system cleanup
2085         https://bugs.webkit.org/show_bug.cgi?id=144566
2086
2087         Reviewed by Darin Adler.
2088
2089         * CMakeLists.txt:
2090
2091 2015-05-04  Andreas Kling  <akling@apple.com>
2092
2093         Optimize WeakBlock's "reap" and "visit" operations.
2094         <https://webkit.org/b/144585>
2095
2096         Reviewed by Geoffrey Garen.
2097
2098         WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
2099         That function was really written with conservative roots marking in mind, and will do a bunch
2100         of sanity and bounds checks.
2101
2102         For weaks, we know that the pointer will have been a valid cell pointer into a block
2103         of appropriate cell size, so we can skip a lot of the checks.
2104
2105         We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
2106         MarkedBlock::blockFor() for every single cell when iterating.
2107
2108         Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
2109         WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
2110         be pointing to any live cells, and the only operation that will run on the block is sweep().
2111
2112         Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
2113         In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
2114         This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
2115
2116         This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
2117         what looks like a 1% speedup locally.
2118
2119         * heap/MarkedBlock.cpp:
2120         (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
2121
2122         * heap/MarkedBlock.h:
2123         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
2124         block's state is known to be either Marked or Retired.
2125
2126         (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
2127         would report that all cells are live anyway.
2128
2129         * heap/WeakBlock.cpp:
2130         (JSC::WeakBlock::create):
2131         (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
2132
2133         (JSC::WeakBlock::visit):
2134         (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
2135
2136         * heap/WeakBlock.h:
2137         (JSC::WeakBlock::disconnectMarkedBlock): Added.
2138         * heap/WeakSet.cpp:
2139         (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
2140         ownership to Heap until it can die peacefully.
2141
2142         (JSC::WeakSet::addAllocator):
2143         * heap/WeakSet.h:
2144         (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
2145
2146 2015-05-04  Basile Clement  <basile_clement@apple.com>
2147
2148         Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
2149         https://bugs.webkit.org/show_bug.cgi?id=144587
2150
2151         Rubber stamped by Filip Pizlo.
2152
2153         When sinking object allocations, we ensure in
2154         determineMaterializationPoints that whenever an allocation is
2155         materialized on a path to a block, it is materialized in all such
2156         paths. Thus when running the SSA calculator to place Phis in
2157         placeMaterializationPoints, we can't encounter a situation where some
2158         Upsilons are referring to a materialization while others are referring
2159         to the phantom object.
2160
2161         This replaces the code that was adding a materialization late in
2162         placeMaterializationPoints to handle that case by an assertion that it
2163         does not happen, which will make
2164         https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
2165
2166         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2167         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2168
2169 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2170
2171         Extending undefined in class syntax should throw a TypeError
2172         https://bugs.webkit.org/show_bug.cgi?id=144284
2173
2174         Reviewed by Darin Adler.
2175
2176         The bug was caused by op_eq_null evaluating to true when compared to undefined.
2177         Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
2178
2179         We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
2180
2181         * bytecompiler/NodesCodegen.cpp:
2182         (JSC::ClassExprNode::emitBytecode):
2183
2184 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2185
2186         new super should be a syntax error
2187         https://bugs.webkit.org/show_bug.cgi?id=144282
2188
2189         Reviewed by Joseph Pecoraro.
2190
2191         Disallow "new super" as ES6 spec doesn't allow this.
2192
2193         * parser/Parser.cpp:
2194         (JSC::Parser<LexerType>::parseMemberExpression):
2195
2196 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2197
2198         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
2199         https://bugs.webkit.org/show_bug.cgi?id=144265
2200
2201         Reviewed by Geoffrey Garen.
2202
2203         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
2204         for a static function if the parent has that property slot. JSCallbackObject::put 
2205         did not maintain this symmetry of also calling ::put on the parent if the parent 
2206         has the property. We should ensure that this symmetry exists.
2207
2208         * API/JSCallbackObjectFunctions.h:
2209         (JSC::JSCallbackObject<Parent>::put):
2210         * API/tests/testapi.c:
2211         * API/tests/testapi.js:
2212         (globalStaticFunction2):
2213         (this.globalStaticFunction2):
2214         (iAmNotAStaticFunction):
2215         (this.iAmNotAStaticFunction):
2216
2217 2015-05-04  Andreas Kling  <akling@apple.com>
2218
2219         Make ExecState::vm() branchless in release builds.
2220         <https://webkit.org/b/144586>
2221
2222         Reviewed by Geoffrey Garen.
2223
2224         Avoid null checking the ExecState's callee() before getting the
2225         VM from it. The code was already dereferencing it anyway, since we
2226         know it's not gonna be null.
2227
2228         * runtime/JSCellInlines.h:
2229         (JSC::ExecState::vm):
2230
2231 2015-05-04  Basile Clement  <basile_clement@apple.com>
2232
2233         Object allocation not sinking properly through CheckStructure
2234         https://bugs.webkit.org/show_bug.cgi?id=144465
2235
2236         Reviewed by Filip Pizlo.
2237
2238         Currently, sinking an allocation through a CheckStructure will
2239         completely ignore all structure checking, which is obviously wrong.
2240
2241         A CheckStructureImmediate node type was present for that purpose, but
2242         the CheckStructures were not properly replaced.  This ensures that
2243         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
2244         sunk through, and that structure checking happens correctly.
2245
2246         * dfg/DFGNode.h:
2247         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
2248         (JSC::DFG::Node::hasStructureSet):
2249         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2250         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2251         * ftl/FTLLowerDFGToLLVM.cpp:
2252         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
2253         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
2254         (JSC::FTL::LowerDFGToLLVM::checkStructure):
2255         * tests/stress/sink_checkstructure.js: Added.
2256         (foo):
2257
2258 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
2259
2260         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
2261         https://bugs.webkit.org/show_bug.cgi?id=144476
2262
2263         Reviewed by Sam Weinig.
2264
2265         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
2266
2267         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
2268         to my knowledge, the topic of how to optimize it is not covered in any
2269         literature about sorting.
2270
2271         On the slowest jQuery sorting test -- prevAll -- our new
2272         Array.prototype.sort, compared to its predecessor, performed 12% fewer
2273         comparisons and requireed 10X less overhead per comparison. Yet, it was
2274         slower.
2275
2276         It was slower because it inadvertantly increased the average cost of the
2277         comparison function by 2X. jQuery uses compareDocumentPosition to compare
2278         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
2279         required to traverse backwards from b to a. In prevAll, we encounter the
2280         worst case for merge sort of compareDocumentPosition: A long list of DOM
2281         nodes in mostly reverse order. In this case, merge sort will sequentially
2282         compareDocumentPosition(a, b), where a is not reachable backwards from
2283         b, and therefore compareDocumentPosition will traverse the whole sibling
2284         list.
2285
2286         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
2287
2288         This is a pretty silly thing to do, but it is harmless, and jQuery is
2289         popular, so let's do it.
2290
2291         We do not risk suffering the same problem in reverse when sorting a long
2292         list of DOM nodes in forward order. (We still have a 37% speedup on the
2293         nextAll benchmark.) The reason is that merge sort performs 2X fewer
2294         comparisons when the list is already sorted, so we can worry less about
2295         the cost of each comparison.
2296
2297         A fully principled soultion to this problem would probably do something
2298         like Python's timsort, which special-cases ordered ranges to perform
2299         only O(n) comparisons. But that would contradict our original
2300         goal of just having something simple that works.
2301
2302         Another option is for elements to keep a compareDocumentPosition cache,
2303         like a node list cache, which allows you to determine the absolute
2304         position of a node using a hash lookup. I will leave this as an exercise
2305         for kling.
2306
2307         * builtins/Array.prototype.js:
2308         (sort.merge): Compare in an order that is favorable to a comparator
2309         that calls compareDocumentPosition.
2310
2311 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2312
2313         [cmake] Fix generate-js-builtins related incremental build issue
2314         https://bugs.webkit.org/show_bug.cgi?id=144094
2315
2316         Reviewed by Michael Saboff.
2317
2318         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
2319         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2320         * DerivedSources.make:
2321         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2322         * generate-js-builtins: Accept input files and input directory too.
2323
2324 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
2325
2326         Make some static data const
2327         https://bugs.webkit.org/show_bug.cgi?id=144552
2328
2329         Reviewed by Andreas Kling.
2330         
2331         Turn characterSetInfo into const data.
2332
2333         * yarr/YarrCanonicalizeUCS2.cpp:
2334         * yarr/YarrCanonicalizeUCS2.h:
2335
2336 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2337
2338         TypeOf should be fast
2339         https://bugs.webkit.org/show_bug.cgi?id=144396
2340
2341         Reviewed by Geoffrey Garen.
2342         
2343         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
2344         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
2345         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
2346         
2347         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
2348         rely heavily on C++ calls to fulfill their function.
2349         
2350         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
2351         
2352         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
2353         This means that if the TypeOf is dominated by any type checks, we will automatically prune
2354         out cases that are redundant.
2355         
2356         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
2357         code generation is designed to be reusable.
2358         
2359         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
2360         the exotic call trap hook. That hook is now in a deeper slow path than before.
2361
2362         * CMakeLists.txt:
2363         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2364         * JavaScriptCore.xcodeproj/project.pbxproj:
2365         * dfg/DFGClobberize.h:
2366         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
2367         * dfg/DFGFixupPhase.cpp:
2368         (JSC::DFG::FixupPhase::fixupNode):
2369         * dfg/DFGHeapLocation.cpp:
2370         (WTF::printInternal):
2371         * dfg/DFGHeapLocation.h:
2372         * dfg/DFGOperations.cpp:
2373         * dfg/DFGOperations.h:
2374         * dfg/DFGSpeculativeJIT.cpp:
2375         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
2376         (JSC::DFG::SpeculativeJIT::compileIsFunction):
2377         (JSC::DFG::SpeculativeJIT::compileTypeOf):
2378         * dfg/DFGSpeculativeJIT.h:
2379         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
2380         (JSC::DFG::SpeculativeJIT::callOperation):
2381         * dfg/DFGSpeculativeJIT32_64.cpp:
2382         (JSC::DFG::SpeculativeJIT::compile):
2383         * dfg/DFGSpeculativeJIT64.cpp:
2384         (JSC::DFG::SpeculativeJIT::compile):
2385         * ftl/FTLCapabilities.cpp:
2386         (JSC::FTL::canCompile):
2387         * ftl/FTLIntrinsicRepository.h:
2388         * ftl/FTLLowerDFGToLLVM.cpp:
2389         (JSC::FTL::LowerDFGToLLVM::compileNode):
2390         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
2391         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
2392         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
2393         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
2394         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
2395         * ftl/FTLSwitchCase.h:
2396         (JSC::FTL::SwitchCase::SwitchCase):
2397         * jit/AssemblyHelpers.h:
2398         (JSC::AssemblyHelpers::branchIfNotEqual):
2399         (JSC::AssemblyHelpers::branchIfEqual):
2400         (JSC::AssemblyHelpers::branchIfNumber):
2401         (JSC::AssemblyHelpers::branchIfNotNumber):
2402         (JSC::AssemblyHelpers::branchIfBoolean):
2403         (JSC::AssemblyHelpers::branchIfNotBoolean):
2404         (JSC::AssemblyHelpers::boxBooleanPayload):
2405         (JSC::AssemblyHelpers::boxBoolean):
2406         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
2407         * jit/JITOperations.h:
2408         * runtime/SmallStrings.h:
2409         (JSC::SmallStrings::typeString):
2410         * runtime/TypeofType.cpp: Added.
2411         (WTF::printInternal):
2412         * runtime/TypeofType.h: Added.
2413         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
2414
2415 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2416
2417         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
2418
2419         * dfg/DFGLICMPhase.cpp:
2420         (JSC::DFG::LICMPhase::attemptHoist):
2421
2422 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2423
2424         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
2425         https://bugs.webkit.org/show_bug.cgi?id=144525.
2426
2427         * dfg/DFGLICMPhase.cpp:
2428         (JSC::DFG::LICMPhase::attemptHoist):
2429         * dfg/DFGPhantomInsertionPhase.cpp:
2430
2431 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
2432
2433         Static property hashtable should only lookup with non-symbol key
2434         https://bugs.webkit.org/show_bug.cgi?id=144438
2435
2436         Reviewed by Darin Adler.
2437
2438         Static property hashtable compares the Identifier's uid
2439         with the normal C string without interning it.
2440         So this comparison is performed in their contents.
2441         As the result, in this comparison, symbol-ness is not considered.
2442
2443         So if accidentally the hash collision occur with the symbol and the string
2444         and they have the same contents, the hash table entry is looked up incorrectly.
2445
2446         * runtime/Lookup.h:
2447         (JSC::HashTable::entry):
2448
2449 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
2450
2451         Class syntax should allow string and numeric identifiers for method names
2452         https://bugs.webkit.org/show_bug.cgi?id=144254
2453
2454         Reviewed by Darin Adler.
2455
2456         Added the support for string and numeric identifiers in class syntax.
2457
2458         * parser/Parser.cpp:
2459         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
2460         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
2461         outside a class constructor as it should be.
2462         (JSC::Parser<LexerType>::parseFunctionDeclaration):
2463         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
2464         element to allow numeric and string method names. For both of those method names, parse it here instead
2465         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
2466         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
2467         this function is never used to parse a class method.
2468         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
2469         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
2470         * parser/Parser.h:
2471         * parser/SyntaxChecker.h:
2472         (JSC::SyntaxChecker::createProperty):
2473
2474 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2475
2476         FTL should use AI more
2477         https://bugs.webkit.org/show_bug.cgi?id=144500
2478
2479         Reviewed by Oliver Hunt.
2480         
2481         This makes our type check folding even more comprehensive by ensuring that even if the FTL
2482         decides to emit some checks, it will still do another query to the abstract interpreter to
2483         see if the check is necessary. This helps with cases where we decided early on to speculate
2484         one way, but later proved a more specific type of the value in question, and the constant
2485         folder didn't catch it.
2486         
2487         This also makes it more natural to query the abstract interpreter. For example, if you just
2488         want the proven type, you can now say provenType(node) or provenType(edge).
2489
2490         * dfg/DFGArrayMode.cpp:
2491         (JSC::DFG::ArrayMode::alreadyChecked):
2492         * dfg/DFGArrayMode.h:
2493         * ftl/FTLLowerDFGToLLVM.cpp:
2494         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
2495         (JSC::FTL::LowerDFGToLLVM::compileToThis):
2496         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
2497         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
2498         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
2499         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2500         (JSC::FTL::LowerDFGToLLVM::compileGetById):
2501         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
2502         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
2503         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
2504         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
2505         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
2506         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
2507         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
2508         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
2509         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
2510         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
2511         (JSC::FTL::LowerDFGToLLVM::compileIsString):
2512         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
2513         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
2514         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
2515         (JSC::FTL::LowerDFGToLLVM::baseIndex):
2516         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
2517         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
2518         (JSC::FTL::LowerDFGToLLVM::boolify):
2519         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
2520         (JSC::FTL::LowerDFGToLLVM::lowInt32):
2521         (JSC::FTL::LowerDFGToLLVM::lowInt52):
2522         (JSC::FTL::LowerDFGToLLVM::lowCell):
2523         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
2524         (JSC::FTL::LowerDFGToLLVM::lowDouble):
2525         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
2526         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
2527         (JSC::FTL::LowerDFGToLLVM::isNumber):
2528         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
2529         (JSC::FTL::LowerDFGToLLVM::isNotCell):
2530         (JSC::FTL::LowerDFGToLLVM::isCell):
2531         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
2532         (JSC::FTL::LowerDFGToLLVM::isMisc):
2533         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
2534         (JSC::FTL::LowerDFGToLLVM::isBoolean):
2535         (JSC::FTL::LowerDFGToLLVM::isNotOther):
2536         (JSC::FTL::LowerDFGToLLVM::isOther):
2537         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
2538         (JSC::FTL::LowerDFGToLLVM::isObject):
2539         (JSC::FTL::LowerDFGToLLVM::isNotObject):
2540         (JSC::FTL::LowerDFGToLLVM::isNotString):
2541         (JSC::FTL::LowerDFGToLLVM::isString):
2542         (JSC::FTL::LowerDFGToLLVM::isFunction):
2543         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
2544         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
2545         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
2546         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
2547         (JSC::FTL::LowerDFGToLLVM::abstractValue):
2548         (JSC::FTL::LowerDFGToLLVM::provenType):
2549         (JSC::FTL::LowerDFGToLLVM::provenValue):
2550         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
2551
2552 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
2553
2554         USE(...) macro should expect unprefixed variables
2555         https://bugs.webkit.org/show_bug.cgi?id=144454
2556
2557         Reviewed by Daniel Bates.
2558
2559         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
2560
2561 2015-05-01  Jordan Harband  <ljharb@gmail.com>
2562
2563         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
2564         https://bugs.webkit.org/show_bug.cgi?id=144314
2565
2566         Reviewed by Darin Adler.
2567
2568         Fixing handling of Infinity position args, per
2569         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
2570         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
2571         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
2572
2573         * runtime/StringPrototype.cpp:
2574         (JSC::clampInt32):
2575         (JSC::stringProtoFuncStartsWith):
2576         (JSC::stringProtoFuncEndsWith):
2577         (JSC::stringProtoFuncIncludes):
2578
2579 2015-05-01  Basile Clement  <basile_clement@apple.com>
2580
2581         Math.abs() returns negative
2582         https://bugs.webkit.org/show_bug.cgi?id=137827
2583
2584         Reviewed by Michael Saboff.
2585
2586         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
2587         identity function.
2588
2589         * dfg/DFGAbstractInterpreterInlines.h:
2590         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2591         * tests/stress/math-abs-positive.js: Added, was previously failing.
2592         (foo):
2593
2594 2015-05-01  Basile Clement  <basile_clement@apple.com>
2595
2596         Function allocation sinking shouldn't be performed on singleton functions
2597         https://bugs.webkit.org/show_bug.cgi?id=144166
2598
2599         Reviewed by Geoffrey Garen.
2600
2601         Function allocations usually are free of any other side effects, but
2602         this is not the case for allocations performed while the underlying
2603         FunctionExecutable is still a singleton (as this allogation will fire
2604         watchpoints invalidating code that depends on it being a singleton).
2605         As the object allocation sinking phase assumes object allocation is
2606         free of side-effects, sinking these allocations is not correct.
2607
2608         This also means that when materializing a function allocation on OSR
2609         exit, that function's executable will never be a singleton, and we don't have
2610         to worry about its watchpoint, allowing us to use
2611         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
2612         JSFunction::create.
2613
2614         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2615         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2616         * ftl/FTLOperations.cpp:
2617         (JSC::FTL::operationMaterializeObjectInOSR):
2618
2619 2015-04-30  Jon Davis  <jond@apple.com>
2620
2621         Web Inspector: console should show an icon for console.info() messages
2622         https://bugs.webkit.org/show_bug.cgi?id=18530
2623
2624         Reviewed by Timothy Hatcher.
2625
2626         * inspector/ConsoleMessage.cpp:
2627         (Inspector::messageLevelValue):
2628         * inspector/protocol/Console.json:
2629         * runtime/ConsoleClient.cpp:
2630         (JSC::appendMessagePrefix):
2631         * runtime/ConsolePrototype.cpp:
2632         (JSC::ConsolePrototype::finishCreation):
2633         (JSC::consoleProtoFuncInfo):
2634         * runtime/ConsoleTypes.h:
2635
2636 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2637
2638         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
2639         https://bugs.webkit.org/show_bug.cgi?id=144462
2640
2641         Reviewed by Geoffrey Garen and Mark Lam.
2642         
2643         At some point we started adding representation-agnostic helpers for doing common type tests.
2644         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
2645         they had overlapping powers, though SpeculativeJIT was a bit better.
2646         
2647         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
2648         better because now all of these helpers can be used in all of the assembly-based JITs, not
2649         just the DFG. It also settles on what I find to be a slightly better naming convention.
2650         For example where we previously would have said branchIsString, now we say
2651         branchIfString. Similarly, branchNotString becomes branchIfNotString.
2652
2653         * dfg/DFGSpeculativeJIT.cpp:
2654         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
2655         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
2656         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
2657         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
2658         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
2659         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
2660         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
2661         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
2662         (JSC::DFG::SpeculativeJIT::speculateObject):
2663         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
2664         (JSC::DFG::SpeculativeJIT::speculateString):
2665         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
2666         (JSC::DFG::SpeculativeJIT::speculateNotCell):
2667         (JSC::DFG::SpeculativeJIT::speculateOther):
2668         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
2669         (JSC::DFG::SpeculativeJIT::emitSwitchString):
2670         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
2671         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
2672         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
2673         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
2674         * dfg/DFGSpeculativeJIT.h:
2675         * dfg/DFGSpeculativeJIT32_64.cpp:
2676         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
2677         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
2678         (JSC::DFG::SpeculativeJIT::emitCall):
2679         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2680         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
2681         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2682         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2683         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2684         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2685         (JSC::DFG::SpeculativeJIT::compile):
2686         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
2687         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
2688         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
2689         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
2690         * dfg/DFGSpeculativeJIT64.cpp:
2691         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
2692         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
2693         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2694         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
2695         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2696         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2697         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2698         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2699         (JSC::DFG::SpeculativeJIT::compile):
2700         (JSC::DFG::SpeculativeJIT::writeBarrier):
2701         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
2702         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
2703         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
2704         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
2705         * jit/AssemblyHelpers.h:
2706         (JSC::AssemblyHelpers::branchIfCell):
2707         (JSC::AssemblyHelpers::branchIfOther):
2708         (JSC::AssemblyHelpers::branchIfNotOther):
2709         (JSC::AssemblyHelpers::branchIfObject):
2710         (JSC::AssemblyHelpers::branchIfNotObject):
2711         (JSC::AssemblyHelpers::branchIfType):
2712         (JSC::AssemblyHelpers::branchIfNotType):
2713         (JSC::AssemblyHelpers::branchIfString):
2714         (JSC::AssemblyHelpers::branchIfNotString):
2715         (JSC::AssemblyHelpers::branchIfSymbol):
2716         (JSC::AssemblyHelpers::branchIfNotSymbol):
2717         (JSC::AssemblyHelpers::branchIfFunction):
2718         (JSC::AssemblyHelpers::branchIfNotFunction):
2719         (JSC::AssemblyHelpers::branchIfEmpty):
2720         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
2721         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
2722         * jit/JITPropertyAccess.cpp:
2723         (JSC::JIT::emitScopedArgumentsGetByVal):
2724
2725 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2726
2727         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
2728         https://bugs.webkit.org/show_bug.cgi?id=144463
2729
2730         Reviewed by Benjamin Poulain.
2731         
2732         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
2733         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
2734         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
2735         converting the boolean into an integer. But as part of doing that, it would try to
2736         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
2737         and it would try to figure out if the addition might overflow. Part of that logic
2738         involved checking if the immediate is either a boolean or a sufficiently small integer.
2739         But: it would check if it's a sufficiently small integer before checking if it was a
2740         boolean, so it would try to call asNumber() on the boolean.
2741         
2742         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
2743         case was previously never hit until I wrote these tests, and so we never knew that
2744         calling asNumber() on a boolean was wrong.
2745         
2746         The fix is super simple: the expression should just check for boolean first.
2747         
2748         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
2749         garbage, and that's OK, since we'd take the boolean case anyway.
2750
2751         * dfg/DFGGraph.h:
2752         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
2753
2754 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2755
2756         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
2757
2758         * jit/JITOperations.cpp:
2759
2760 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2761
2762         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
2763         particular that they cannot change their minds and may be called from compiler threads.
2764
2765         Rubber stamped by Geoffrey Garen.
2766
2767         * runtime/JSCell.h:
2768
2769 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
2770
2771         DFG Is<Blah> versions of TypeOf should fold based on proven input type
2772         https://bugs.webkit.org/show_bug.cgi?id=144409
2773
2774         Reviewed by Geoffrey Garen.
2775         
2776         We were missing some obvious folding opportunities here. I don't know how this affects real
2777         code, but in general, we like to ensure that our constant folding is comprehensive. So this
2778         is more about placating my static analysis OCD than anything else.
2779         
2780         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
2781
2782         * dfg/DFGAbstractInterpreterInlines.h:
2783         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2784
2785 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
2786
2787         Use the default hash value for Symbolized StringImpl
2788         https://bugs.webkit.org/show_bug.cgi?id=144347
2789
2790         Reviewed by Darin Adler.
2791
2792         Before this patch, symbolized StringImpl* has a special hash value
2793         to avoid the hash collision with the other normal StringImpl*.
2794         I guess that it is introduced when private symbols are introduced.
2795         However, it prevents using symbolized StringImpl* in the other place
2796         For example, using it as WTFString cause a problem because of its special hash value.
2797
2798         When only using private symbols, they are not exposed to the outside of JSC,
2799         so we can handle it carefully. But now, it's extended to symbols.
2800         So I think storing a special hash value in StringImpl* causes an error.
2801
2802         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
2803         And to provide significantly different hash value when using it as symbol,
2804         store the additional hash value in symbolized StringImpl*. It is used when
2805         the hash value is required by IdentifierRepHash.
2806
2807         * runtime/Identifier.h:
2808         (JSC::IdentifierRepHash::hash):
2809         * runtime/Lookup.h:
2810         (JSC::HashTable::entry):
2811         * runtime/PropertyMapHashTable.h:
2812         (JSC::PropertyTable::find):
2813         (JSC::PropertyTable::get):
2814         * runtime/Structure.cpp:
2815         (JSC::PropertyTable::checkConsistency):
2816
2817 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
2818
2819         [JSC] Remove RageConvert array conversion
2820         https://bugs.webkit.org/show_bug.cgi?id=144433
2821
2822         Reviewed by Filip Pizlo.
2823
2824         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
2825         pretty hard:
2826         -The indexing types shows that the array access varies between Int32 and DoubleArray.
2827         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
2828          An Arrayify node would convert the Int32 to that type.
2829         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
2830          node would use RageConvert instead of Convert.
2831         -The Arrayify for that GetByVal with RageConvert would not convert the array to
2832          Contiguous.
2833         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
2834          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
2835          fail systematically and we never get to run the later code.
2836
2837         Getting rid of RageConvert fixes the problem and does not seems to have any
2838         negative side effect on other benchmarks.
2839
2840         The improvments on Kraken are:
2841             -stanford-crypto-aes: definitely 1.0915x faster.
2842             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
2843             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
2844
2845         * dfg/DFGAbstractInterpreterInlines.h:
2846         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2847         * dfg/DFGArrayMode.cpp:
2848         (JSC::DFG::ArrayMode::refine):
2849         (JSC::DFG::arrayConversionToString):
2850         * dfg/DFGArrayMode.h:
2851         * dfg/DFGArrayifySlowPathGenerator.h:
2852         * dfg/DFGFixupPhase.cpp:
2853         (JSC::DFG::FixupPhase::fixupNode):
2854         * dfg/DFGOperations.cpp:
2855         * dfg/DFGOperations.h:
2856         * dfg/DFGPredictionPropagationPhase.cpp:
2857         (JSC::DFG::PredictionPropagationPhase::propagate):
2858         * dfg/DFGTypeCheckHoistingPhase.cpp:
2859         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2860         * ftl/FTLLowerDFGToLLVM.cpp:
2861         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
2862         * runtime/JSObject.cpp:
2863         (JSC::JSObject::convertDoubleToContiguous):
2864         (JSC::JSObject::ensureContiguousSlow):
2865         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
2866         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
2867         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
2868         * runtime/JSObject.h:
2869         (JSC::JSObject::rageEnsureContiguous): Deleted.
2870
2871 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
2872
2873         Gracefully handle missing auto pause key on remote inspector setup
2874         https://bugs.webkit.org/show_bug.cgi?id=144411
2875
2876         Reviewed by Timothy Hatcher.
2877
2878         * inspector/remote/RemoteInspector.mm:
2879         (Inspector::RemoteInspector::receivedSetupMessage):
2880
2881 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
2882
2883         NodeList has issues with Symbol and empty string
2884         https://bugs.webkit.org/show_bug.cgi?id=144310
2885
2886         Reviewed by Darin Adler.
2887
2888         * runtime/PropertyName.h:
2889         (JSC::PropertyName::isSymbol):
2890         Helper to check if the PropertyName is a string or symbol property.
2891
2892 2015-04-29  Alex Christensen  <achristensen@webkit.org>
2893
2894         Fix non-cygwin incremental builds on Windows.
2895         https://bugs.webkit.org/show_bug.cgi?id=143264
2896
2897         Reviewed by Brent Fulgham.
2898
2899         * generate-js-builtins:
2900         Remove stale headers before calling os.rename to replace them.
2901
2902 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
2903
2904         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
2905         https://bugs.webkit.org/show_bug.cgi?id=144397
2906
2907         Reviewed by Andreas Kling.
2908         
2909         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
2910         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
2911         making a getCallData() call if it isn't necessary.
2912
2913         * API/JSCallbackObject.h:
2914         * runtime/InternalFunction.h:
2915         * runtime/JSTypeInfo.h:
2916         (JSC::TypeInfo::typeOfShouldCallGetCallData):
2917         * runtime/Operations.cpp:
2918         (JSC::jsTypeStringForValue):
2919         * tests/stress/type-of-functions-and-objects.js: Added.
2920         (foo):
2921         (bar):
2922         (baz):
2923         (fuzz):
2924         (expect):
2925         (test):
2926
2927 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
2928
2929         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
2930         https://bugs.webkit.org/show_bug.cgi?id=144013
2931
2932         Reviewed by Mark Lam.
2933
2934         This patch implements Array.prototype.sort in JavaScript, removing the
2935         C++ implementations. It is simpler and less error-prone to express our
2936         operations in JavaScript, which provides memory safety, exception safety,
2937         and recursion safety.
2938
2939         The performance result is mixed, but net positive in my opinion. It's
2940         difficult to enumerate all the results, since we used to have so many
2941         different sorting modes, and there are lots of different data patterns
2942         across which you might want to measure sorting. Suffice it to say:
2943
2944             (*) The benchmarks we track are faster or unchanged.
2945
2946             (*) Sorting random input using a comparator -- which we think is
2947             common -- is 3X faster.
2948
2949             (*) Sorting random input in a non-array object -- which jQuery does
2950             -- is 4X faster.
2951
2952             (*) Sorting random input in a compact array of integers using a
2953             trivial pattern-matchable comparator is 2X *slower*.
2954
2955         * builtins/Array.prototype.js:
2956         (sort.min):
2957         (sort.stringComparator):
2958         (sort.compactSparse): Special case compaction for sparse arrays because
2959         we don't want to hang when sorting new Array(BIG).
2960
2961         (sort.compact):
2962         (sort.merge):
2963         (sort.mergeSort): Use merge sort because it's a reasonably efficient
2964         stable sort. We have evidence that some sites depend on stable sort,
2965         even though the ES6 spec does not mandate it. (See
2966         <http://trac.webkit.org/changeset/33967>.)
2967
2968         This is a textbook implementation of merge sort with three optimizations:
2969
2970             (1) Use iteration instead of recursion;
2971
2972             (2) Use array subscripting instead of array copying in order to
2973             create logical sub-lists without creating physical sub-lists;
2974
2975             (3) Swap src and dst at each iteration instead of copying src into
2976             dst, and only copy src into the subject array at the end if src is
2977             not the subject array.
2978
2979         (sort.inflate):
2980         (sort.comparatorSort):
2981         (sort): Sort in JavaScript for the win.
2982
2983         * builtins/BuiltinExecutables.cpp:
2984         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
2985         names so we can use helper functions.
2986
2987         * bytecode/CodeBlock.h:
2988         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
2989         * bytecode/UnlinkedCodeBlock.cpp:
2990         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2991         * bytecode/UnlinkedCodeBlock.h:
2992         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
2993         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
2994         * bytecompiler/BytecodeGenerator.cpp:
2995         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
2996         * bytecompiler/BytecodeGenerator.h:
2997         * bytecompiler/NodesCodegen.cpp:
2998         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
2999         on pattern matching anymore. This was mainly an optimization to avoid 
3000         the overhead of calling from C++ to JS, which we now avoid by
3001         sorting in JS.
3002
3003         * heap/Heap.cpp:
3004         (JSC::Heap::markRoots):
3005         (JSC::Heap::pushTempSortVector): Deleted.
3006         (JSC::Heap::popTempSortVector): Deleted.
3007         (JSC::Heap::visitTempSortVectors): Deleted.
3008         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
3009         in JavaScript using a normal JavaScript array for our temporary storage.
3010
3011         * parser/Parser.cpp:
3012         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
3013         helper functions.
3014
3015         * runtime/ArrayPrototype.cpp:
3016         (JSC::isNumericCompareFunction): Deleted.
3017         (JSC::attemptFastSort): Deleted.
3018         (JSC::performSlowSort): Deleted.
3019         (JSC::arrayProtoFuncSort): Deleted.
3020
3021         * runtime/CommonIdentifiers.h: New strings used by sort.
3022
3023         * runtime/JSArray.cpp:
3024         (JSC::compareNumbersForQSortWithInt32): Deleted.
3025         (JSC::compareNumbersForQSortWithDouble): Deleted.
3026         (JSC::compareNumbersForQSort): Deleted.
3027         (JSC::compareByStringPairForQSort): Deleted.
3028         (JSC::JSArray::sortNumericVector): Deleted.
3029         (JSC::JSArray::sortNumeric): Deleted.
3030         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
3031         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
3032         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
3033         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
3034         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
3035         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
3036         (JSC::JSArray::sortCompactedVector): Deleted.
3037         (JSC::JSArray::sort): Deleted.
3038         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
3039         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
3040         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
3041         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
3042         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
3043         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
3044         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
3045         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
3046         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
3047         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
3048         (JSC::JSArray::sortVector): Deleted.
3049         (JSC::JSArray::compactForSorting): Deleted.
3050         * runtime/JSArray.h:
3051
3052         * runtime/JSGlobalObject.cpp:
3053         (JSC::JSGlobalObject::init):
3054         * runtime/ObjectConstructor.cpp:
3055         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
3056         by sort.
3057
3058 2015-04-29  Mark Lam  <mark.lam@apple.com>
3059
3060         Safari WebKit crash when loading Google Spreadsheet.
3061         https://bugs.webkit.org/show_bug.cgi?id=144020
3062
3063         Reviewed by Filip Pizlo.
3064
3065         The bug is that the object allocation sinking phase did not account for a case
3066         where a property of a sunken object is only initialized on one path and not
3067         another.  As a result, on the path where the property is not initialized, we'll
3068         encounter an Upsilon with a BottomValue (which is not allowed by definition).
3069
3070         The fix is to use a JSConstant(undefined) as the bottom value instead (of
3071         BottomValue).  If the property is uninitialized, it should still be accessible
3072         and have the value undefined.
3073
3074         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3075         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
3076         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
3077         (foo):
3078         (foo2):
3079
3080 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
3081
3082         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
3083         https://bugs.webkit.org/show_bug.cgi?id=144257
3084
3085         Reviewed by Darin Adler.
3086
3087         SHA1 is used to calculate CodeBlockHash.
3088         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
3089         However, the source code can contain null character.
3090         So when performing `strlen` on the source code's CString, it returns the incorrect length.
3091         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
3092
3093         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
3094         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
3095
3096         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
3097         is not correct. Because
3098
3099         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
3100         2. If CString can contain a null character, this assertion becomes incorrect.
3101
3102         So this patch just drops the assertion.
3103
3104         In the current implementation, we once convert the entire source code to the newly allocated
3105         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
3106         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
3107         We'll implement it in the separate patch[2].
3108
3109         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
3110         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
3111
3112         * tests/stress/eval-script-contains-null-character.js: Added.
3113         (shouldBe):
3114         (test):
3115         * tests/stress/template-literal-line-terminators.js:
3116         * tests/stress/template-literal-syntax.js:
3117         * tests/stress/template-literal.js:
3118
3119 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
3120
3121         Evict IsEnvironmentRecord from inline type flags
3122         https://bugs.webkit.org/show_bug.cgi?id=144398
3123
3124         Reviewed by Mark Lam and Michael Saboff.
3125         
3126         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
3127         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
3128         and evicts it into the out-of-line type flags. This change has no performance implications
3129         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
3130         where we access it at all is in String.prototype.repeat, and there we already load the
3131         structure anyway.
3132
3133         * runtime/JSTypeInfo.h:
3134         (JSC::TypeInfo::implementsHasInstance):
3135         (JSC::TypeInfo::structureIsImmortal):
3136         (JSC::TypeInfo::isEnvironmentRecord):
3137
3138 2015-04-29  Darin Adler  <darin@apple.com>
3139
3140         [ES6] Implement Unicode code point escapes
3141         https://bugs.webkit.org/show_bug.cgi?id=144377
3142
3143         Reviewed by Antti Koivisto.
3144
3145         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
3146         the header. Made it a non-member class so it doesn't need to be part
3147         of a template. Made it use UChar32 instead of int for the value to
3148         make it clearer what goes into this class.
3149         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
3150         old type() function.
3151         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
3152         parseFourDigitUnicodeHex and added support for code point escapes.
3153         (JSC::isLatin1): Added an overload for UChar32.
3154         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
3155         to call it with a UChar, so no need to overload for that type for now.
3156         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
3157         Also added FIXME about a subtle ES6 change that we might want to make later.
3158         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
3159         to call it with a UChar, so no need to overload for that type for now.
3160         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
3161         don't need to repeat the code twice. Added code to handle code point escapes.
3162         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
3163         code in line.
3164         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
3165         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
3166         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
3167         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
3168         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
3169         the code that handles the escapes, since the code point escape code now
3170         consumes characters while parsing rather than peeking ahead. Test case
3171         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
3172         giving a syntax error.
3173
3174         * parser/Lexer.h: Updated for above changes.
3175
3176         * runtime/StringConstructor.cpp:
3177         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
3178         out 0x10FFFF; clearer this way.
3179
3180 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
3181
3182         [CMake] [GTK] Organize and clean up unused CMake variables
3183         https://bugs.webkit.org/show_bug.cgi?id=144364
3184
3185         Reviewed by Gyuyoung Kim.
3186
3187         * PlatformGTK.cmake: Add variables specific to this project.
3188
3189 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3190
3191         TypeOf should return SpecStringIdent and the DFG should know this
3192         https://bugs.webkit.org/show_bug.cgi?id=144376
3193
3194         Reviewed by Andreas Kling.
3195         
3196         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
3197         
3198         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
3199         bad.
3200
3201         * dfg/DFGAbstractInterpreterInlines.h:
3202         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3203         * dfg/DFGAbstractValue.cpp:
3204         (JSC::DFG::AbstractValue::setType):
3205         * dfg/DFGAbstractValue.h:
3206         (JSC::DFG::AbstractValue::setType):
3207         * dfg/DFGInPlaceAbstractState.cpp:
3208         (JSC::DFG::InPlaceAbstractState::initialize):
3209         * dfg/DFGPredictionPropagationPhase.cpp:
3210         (JSC::DFG::PredictionPropagationPhase::propagate):
3211         * runtime/SmallStrings.cpp:
3212         (JSC::SmallStrings::initialize):
3213         * tests/stress/switch-typeof-indirect.js: Added.
3214         (bar):
3215         (foo):
3216         (test):
3217         * tests/stress/switch-typeof-slightly-indirect.js: Added.
3218         (foo):
3219         (test):
3220         * tests/stress/switch-typeof.js: Added.
3221         (foo):
3222         (test):
3223
3224 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
3225
3226         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
3227         https://bugs.webkit.org/show_bug.cgi?id=144373
3228
3229         Reviewed by Darin Adler.
3230
3231         Revert r181868 as it caused a failure on live.com. We can try
3232         re-enabling this exception after we make idl attributes configurable,
3233         which may have prevented this particular failure.
3234
3235         * runtime/ObjectPrototype.cpp:
3236         (JSC::objectProtoFuncDefineGetter):
3237         (JSC::objectProtoFuncDefineSetter):
3238
3239 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
3240
3241         Deadlock on applications using JSContext on non-main thread
3242         https://bugs.webkit.org/show_bug.cgi?id=144370
3243
3244         Reviewed by Timothy Hatcher.
3245
3246         * inspector/remote/RemoteInspector.mm:
3247         (Inspector::RemoteInspector::singleton):
3248         Prevent a possible deadlock by assuming we can synchronously
3249         run something on the main queue at this time.
3250
3251 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3252
3253         FTL should fully support Switch (it currently lacks the SwitchString variant)
3254         https://bugs.webkit.org/show_bug.cgi?id=144348
3255
3256         Reviewed by Benjamin Poulain.
3257         
3258         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
3259         in LayoutTests/js/regress.
3260
3261         * dfg/DFGCommon.cpp:
3262         (JSC::DFG::stringLessThan):
3263         * dfg/DFGCommon.h:
3264         * dfg/DFGOperations.cpp:
3265         * dfg/DFGOperations.h:
3266         * dfg/DFGSpeculativeJIT.cpp:
3267         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
3268         * dfg/DFGSpeculativeJIT.h:
3269         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
3270         * ftl/FTLCapabilities.cpp:
3271         (JSC::FTL::canCompile):
3272         * ftl/FTLIntrinsicRepository.h:
3273         * ftl/FTLLowerDFGToLLVM.cpp:
3274         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
3275         (JSC::FTL::LowerDFGToLLVM::switchString):
3276         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
3277         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
3278         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
3279         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
3280         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
3281         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
3282         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
3283         * ftl/FTLOutput.cpp:
3284         (JSC::FTL::Output::check):
3285         * ftl/FTLOutput.h:
3286         * ftl/FTLWeight.h:
3287         (JSC::FTL::Weight::inverse):
3288         * jit/JITOperations.h:
3289
3290 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
3291
3292         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
3293         https://bugs.webkit.org/show_bug.cgi?id=144304
3294
3295         Reviewed by Geoffrey Garen.
3296
3297         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
3298         ENABLE_LLINT_C_LOOP, disabled by default.
3299         * llint/LLIntSlowPaths.cpp:
3300         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
3301
3302 2015-04-28  Commit Queue  <commit-queue@webkit.org>
3303
3304         Unreviewed, rolling out r183514.
3305         https://bugs.webkit.org/show_bug.cgi?id=144359
3306
3307         It broke cloop test bots (Requested by mcatanzaro on #webkit).
3308
3309         Reverted changeset:
3310
3311         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
3312         https://bugs.webkit.org/show_bug.cgi?id=144304
3313         http://trac.webkit.org/changeset/183514
3314
3315 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
3316
3317         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
3318         https://bugs.webkit.org/show_bug.cgi?id=144304
3319
3320         Reviewed by Geoffrey Garen.
3321
3322         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
3323         ENABLE_LLINT_C_LOOP, disabled by default.
3324         * llint/LLIntSlowPaths.cpp:
3325         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
3326
3327 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
3328
3329         Fix common typo "targetting" => "targeting"
3330         https://bugs.webkit.org/show_bug.cgi?id=144349
3331
3332         Reviewed by Daniel Bates.
3333
3334         * bytecode/ExecutionCounter.h:
3335
3336 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
3337
3338         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
3339         https://bugs.webkit.org/show_bug.cgi?id=144328
3340
3341         Reviewed by Andreas Kling.
3342
3343         Update the status of ES6 features.
3344
3345         * features.json:
3346
3347 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3348
3349         DFG should not use or preserve Phantoms during transformations
3350         https://bugs.webkit.org/show_bug.cgi?id=143736
3351
3352         Reviewed by Geoffrey Garen.
3353         
3354         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
3355         no longer necessary to preserve Phantoms during transformations. They are still useful just
3356         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
3357         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
3358         block, we can be sure that so long as the IR pinpoints the place where the value becomes
3359         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
3360         other block would need the value (either for OSR or for DFG execution), then we don't need any
3361         liveness markers.
3362         
3363         So, this removes any places where we inserted Phantoms just for liveness during transformation
3364         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
3365         Check node only keeps its children so long as those children have checks.
3366         
3367         The fact that we no longer convertToPhantom() means that we have to be more careful when
3368         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
3369         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
3370         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
3371         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
3372         GetLocals.
3373         
3374         The only Phantom-like cruft left over after this patch is:
3375         
3376         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
3377           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
3378           the users of the original local's live range in bytecode. This is essential for supporting our
3379           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
3380         
3381         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
3382           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
3383           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
3384           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
3385           treat GetLocal/SetLocal conservatively, this should all be sound.
3386         
3387         This change should be perf-neutral although it does reduce the total work that the compiler
3388         does.
3389
3390         * CMakeLists.txt:
3391         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3392         * JavaScriptCore.xcodeproj/project.pbxproj:
3393         * dfg/DFGAdjacencyList.h:
3394         (JSC::DFG::AdjacencyList::justChecks):
3395         * dfg/DFGArgumentsEliminationPhase.cpp:
3396         * dfg/DFGBasicBlock.cpp:
3397         (JSC::DFG::BasicBlock::replaceTerminal):
3398         * dfg/DFGBasicBlock.h:
3399         (JSC::DFG::BasicBlock::findTerminal):
3400         * dfg/DFGCFGSimplificationPhase.cpp:
3401         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
3402         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
3403         * dfg/DFGCPSRethreadingPhase.cpp:
3404         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
3405         (JSC::DFG::CPSRethreadingPhase::clearVariables):
3406         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
3407         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
3408         * dfg/DFGCSEPhase.cpp:
3409         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
3410         (JSC::DFG::CleanUpPhase::CleanUpPhase):
3411         (JSC::DFG::CleanUpPhase::run):
3412         (JSC::DFG::performCleanUp):
3413         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
3414         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
3415         (JSC::DFG::performPhantomRemoval): Deleted.
3416         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
3417         * dfg/DFGConstantFoldingPhase.cpp:
3418         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3419         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
3420         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
3421         * dfg/DFGDCEPhase.cpp:
3422         (JSC::DFG::DCEPhase::run):
3423         (JSC::DFG::DCEPhase::fixupBlock):
3424         (JSC::DFG::DCEPhase::cleanVariables):
3425         * dfg/DFGFixupPhase.cpp:
3426         (JSC::DFG::FixupPhase::fixupBlock):
3427         (JSC::DFG::FixupPhase::fixupNode):
3428         (JSC::DFG::FixupPhase::convertStringAddUse):
3429         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
3430         (JSC::DFG::FixupPhase::checkArray):
3431         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
3432         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
3433         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
3434         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
3435         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
3436         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
3437         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
3438         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
3439         * dfg/DFGGraph.cpp:
3440         (JSC::DFG::Graph::convertToConstant):
3441         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
3442         * dfg/DFGGraph.h:
3443         * dfg/DFGInsertionSet.h:
3444         (JSC::DFG::InsertionSet::insertCheck):
3445         * dfg/DFGIntegerCheckCombiningPhase.cpp:
3446         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
3447         * dfg/DFGLICMPhase.cpp:
3448         (JSC::DFG::LICMPhase::attemptHoist):
3449         * dfg/DFGNode.cpp:
3450         (JSC::DFG::Node::remove):
3451         * dfg/DFGNode.h:
3452         (JSC::DFG::Node::replaceWith):
3453         (JSC::DFG::Node::convertToPhantom): Deleted.
3454         (JSC::DFG::Node::convertToCheck): Deleted.
3455         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
3456         * dfg/DFGNodeFlags.h:
3457         * dfg/DFGNodeType.h:
3458         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3459         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
3460         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
3461         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
3462         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
3463         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
3464         * dfg/DFGPhantomRemovalPhase.h: Removed.
3465         * dfg/DFGPlan.cpp:
3466         (JSC::DFG::Plan::compileInThreadImpl):
3467         * dfg/DFGPutStackSinkingPhase.cpp:
3468         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
3469         * dfg/DFGResurrectionForValidationPhase.h: Removed.
3470         * dfg/DFGSSAConversionPhase.cpp:
3471         (JSC::DFG::SSAConversionPhase::run):
3472         * dfg/DFGSpeculativeJIT64.cpp:
3473         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
3474         * dfg/DFGStoreBarrierElisionPhase.cpp:
3475         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
3476         * dfg/DFGStrengthReductionPhase.cpp:
3477         (JSC::DFG::StrengthReductionPhase::handleNode):
3478         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
3479         * dfg/DFGValidate.cpp:
3480         (JSC::DFG::Validate::validate):
3481         (JSC::DFG::Validate::validateCPS):
3482         (JSC::DFG::Validate::validateSSA):
3483         * dfg/DFGVarargsForwardingPhase.cpp:
3484         * ftl/FTLLink.cpp:
3485         (JSC::FTL::link):
3486         * ftl/FTLLowerDFGToLLVM.cpp:
3487         (JSC::FTL::LowerDFGToLLVM::compileNode):
3488         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
3489         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
3490
3491 2015-04-28  Andreas Kling  <akling@apple.com>
3492
3493         DFG+FTL should generate efficient code for branching on a string's boolean value.
3494         <https://webkit.org/b/144317>
3495
3496         Reviewed by Geoff Garen & Filip Pizlo
3497
3498         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
3499         instead of dropping out to C++ whenever we branch on a string.
3500
3501         The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
3502         the DFG JIT gets some new codegen logic in this patch.
3503
3504         Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
3505
3506         * dfg/DFGFixupPhase.cpp:
3507         (JSC::DFG::FixupPhase::fixupNode):
3508         * dfg/DFGSpeculativeJIT.cpp:
3509         (JSC::DFG::SpeculativeJIT::emitStringBranch):
3510         * dfg/DFGSpeculativeJIT.h:
3511         * dfg/DFGSpeculativeJIT32_64.cpp:
3512         (JSC::DFG::SpeculativeJIT::emitBranch):
3513         * dfg/DFGSpeculativeJIT64.cpp:
3514         (JSC::DFG::SpeculativeJIT::emitBranch):
3515
3516 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3517
3518         VarargsForwardingPhase should only consider MovHints that have the candidate as a child
3519         https://bugs.webkit.org/show_bug.cgi?id=144340
3520
3521         Reviewed by Michael Saboff and Mark Lam.
3522         
3523         Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
3524         CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
3525         Basically, we'd keep it alive until the end of the block. This maximized the chances of
3526         there being an interfering operation, which would prevent elimination.
3527         
3528         The fix is to only consider MovHints that have the arguments candidate as a child. We only
3529         care to track the liveness of those bytecode locals that would need an arguments object
3530         recovery on OSR exit.
3531         
3532         This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
3533         introduced in http://trac.webkit.org/changeset/183406.
3534
3535         * dfg/DFGVarargsForwardingPhase.cpp:
3536
3537 2015-04-28  Csaba Osztrogonác  <ossy@webkit.org>
3538
3539         Remove WinCE cruft from cmake build system
3540         https://bugs.webkit.org/show_bug.cgi?id=144325
3541
3542         Reviewed by Gyuyoung Kim.
3543
3544         * CMakeLists.txt:
3545         * create_jit_stubs: Removed.
3546
3547 2015-04-27  Andreas Kling  <akling@apple.com>
3548
3549         RegExp matches arrays should use contiguous indexing.
3550         <https://webkit.org/b/144286>
3551
3552         Reviewed by Geoffrey Garen.
3553
3554         We had a custom Structure being used for RegExp matches arrays that would
3555         put the arrays into SlowPutArrayStorageShape mode. This was just left
3556         from when matches arrays were custom, lazily initialized objects.
3557
3558         This change removes that Structure and switches the matches arrays to
3559         using the default ContiguousShape Structure. This allows the FTL JIT
3560         to compile the inner loop of the Octane/regexp benchmark.
3561
3562         Also made a version of initializeIndex() [inline] that takes the indexing
3563         type in an argument, allowing createRegExpMatchesArray() to initialize
3564         the entire array without branching on the indexing type for each entry.
3565
3566         ~3% progression on Octane/regexp.
3567
3568         * runtime/JSGlobalObject.cpp:
3569         (JSC::JSGlobalObject::init):
3570         (JSC::JSGlobalObject::visitChildren):
3571         * runtime/JSGlobalObject.h:
3572         (JSC::JSGlobalObject::mapStructure):
3573         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
3574         * runtime/JSObject.h:
3575         (JSC::JSObject::initializeIndex):
3576         * runtime/RegExpMatchesArray.cpp:
3577         (JSC::createRegExpMatchesArray):
3578
3579 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
3580
3581         FTL failed to initialize arguments.callee on the slow path as well as the fast path
3582         https://bugs.webkit.org/show_bug.cgi?id=144293
3583
3584         Reviewed by Mark Lam.
3585         
3586         The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
3587         to initialize the callee on the common path after the fast and slow path.
3588
3589         * ftl/FTLLowerDFGToLLVM.cpp:
3590         (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
3591         * tests/stress/arguments-callee-uninitialized.js: Added.
3592         (foo):
3593
3594 2015-04-27  Benjamin Poulain  <bpoulain@apple.com>
3595
3596         [JSC] Add support for typed arrays to the Array profiling
3597         https://bugs.webkit.org/show_bug.cgi?id=143913
3598
3599         Reviewed by Filip Pizlo.
3600
3601         This patch adds ArrayModes for every typed arrays. Having that information
3602         let us generate better GetByVal and PutByVal when the type speculation
3603         are not good enough.
3604
3605         A typical case where this is useful is any basic block for which the type
3606         of the object is always more restrictive than the speculation (for example, 
3607         a basic block gated by a branch only taken for on type).
3608
3609         * bytecode/ArrayProfile.cpp:
3610         (JSC::dumpArrayModes):
3611         * bytecode/ArrayProfile.h:
3612         (JSC::arrayModeFromStructure):
3613         * dfg/DFGArrayMode.cpp:
3614         (JSC::DFG::ArrayMode::fromObserved):
3615         (JSC::DFG::ArrayMode::refine):
3616         Maintain the refine() semantic. We do not support OutOfBounds access
3617         for GetByVal on typed array.
3618
3619         * runtime/IndexingType.h:
3620         * tests/stress/typed-array-get-by-val-profiling.js: Added.
3621         (testArray.testCode):
3622         (testArray):
3623         * tests/stress/typed-array-put-by-val-profiling.js: Added.
3624         (testArray.testCode):
3625         (testArray):
3626
3627 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
3628
3629         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
3630         causes many debug test failures.
3631
3632         * runtime/JSGlobalObject.cpp:
3633         (JSC::JSGlobalObject::init):
3634         (JSC::JSGlobalObject::visitChildren):
3635         * runtime/JSGlobalObject.h:
3636         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
3637         * runtime/JSObject.h:
3638         (JSC::JSObject::initializeIndex):
3639         * runtime/RegExpMatchesArray.cpp:
3640         (JSC::createRegExpMatchesArray):
3641
3642 2015-04-27  Andreas Kling  <akling@apple.com>
3643
3644         RegExp matches arrays should use contiguous indexing.
3645         <https://webkit.org/b/144286>
3646
3647         Reviewed by Geoffrey Garen.
3648
3649         We had a custom Structure being used for RegExp matches arrays that would
3650         put the arrays into SlowPutArrayStorageShape mode. This was just left
3651         from when matches arrays were custom, lazily initialized objects.
3652
3653         This change removes that Structure and switches the matches arrays to
3654         using the default ContiguousShape Structure. This allows the FTL JIT
3655         to compile the inner loop of the Octane/regexp benchmark.
3656
3657         Also made a version of initializeIndex() [inline] that takes the indexing
3658         type in an argument, allowing createRegExpMatchesArray() to initialize
3659         the entire array without branching on the indexing type for each entry.
3660
3661         ~3% progression on Octane/regexp.
3662
3663         * runtime/JSGlobalObject.cpp:
3664         (JSC::JSGlobalObject::init):
3665         (JSC::JSGlobalObject::visitChildren):
3666         * runtime/JSGlobalObject.h:
3667         (JSC::JSGlobalObject::mapStructure):
3668         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
3669         * runtime/JSObject.h:
3670         (JSC::JSObject::initializeIndex):
3671         * runtime/RegExpMatchesArray.cpp:
3672         (JSC::createRegExpMatchesArray):
3673
3674 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
3675
3676         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
3677         https://bugs.webkit.org/show_bug.cgi?id=144257
3678
3679         Temporarily disable skip these tests.
3680
3681         * tests/stress/template-literal-line-terminators.js:
3682         * tests/stress/template-literal-syntax.js:
3683         * tests/stress/template-literal.js:
3684
3685 2015-04-27  Basile Clement  <basile_clement@apple.com>
3686
3687         Function allocations shouldn't sink through Put operations
3688         https://bugs.webkit.org/show_bug.cgi?id=144176
3689
3690         Reviewed by Filip Pizlo.
3691
3692         By design, we don't support function allocation sinking through any
3693         related operation ; however object allocation can sink through PutByOffset et
3694         al.
3695
3696         Currently, the checks to prevent function allocation to sink through
3697         these are misguided and do not prevent anything ; function allocation sinking
3698         through these operations is prevented as a side effect of requiring an
3699         AllocatePropertyStorage through which the function allocation is seen as
3700         escaping.
3701
3702         This changes it so that ObjectAllocationSinkingPhase::handleNode()
3703         checks properly that only object allocations sink through related write
3704         operations.
3705
3706         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3707         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
3708         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
3709
3710 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
3711
3712         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
3713         https://bugs.webkit.org/show_bug.cgi?id=143843
3714
3715         Reviewed by Geoffrey Garen.
3716         
3717         It will soon come to pass that Phantom isn't available at the time that
3718         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
3719         a value dies for OSR.
3720         
3721         This is simplified by two things:
3722         
3723         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
3724            before by polishing the API.
3725         
3726         2) This phase already operates on one node at a time and allows itself to do a full search
3727            of the enclosing basic block for that node. This is fine because CreateDirectArguments
3728            and friends is a rarely occurring node. The fact that it operates on one node at a time
3729            makes it even easier to reason about OSR liveness - we just track the list of locals in
3730            which it is live.
3731         
3732         This change has no effect right now but it is a necessary prerequisite to implementing
3733         https://bugs.webkit.org/show_bug.cgi?id=143736.
3734
3735         * dfg/DFGBasicBlock.h:
3736         (JSC::DFG::BasicBlock::tryAt):
3737         * dfg/DFGForAllKills.h:
3738         (JSC::DFG::forAllKilledOperands):
3739         * dfg/DFGPhantomInsertionPhase.cpp:
3740         * dfg/DFGVarargsForwardingPhase.cpp:
3741
3742 2015-04-27  Jordan Harband  <ljharb@gmail.com>
3743
3744         Map#entries and Map#keys error for non-Maps is swapped
3745         https://bugs.webkit.org/show_bug.cgi?id=144253
3746
3747         Reviewed by Simon Fraser.
3748
3749         Correcting error messages on Set/Map methods when called on
3750         incompatible objects.
3751
3752         * runtime/MapPrototype.cpp:
3753         (JSC::mapProtoFuncEntries):
3754         (JSC::mapProtoFuncKeys):
3755         * runtime/SetPrototype.cpp:
3756         (JSC::setProtoFuncEntries):
3757
3758 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
3759
3760         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
3761         https://bugs.webkit.org/show_bug.cgi?id=144186
3762
3763         Reviewed by Geoffrey Garen.
3764         
3765         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
3766         Int32. We may later perform code simplifications based on the proof that this is Int32, and
3767         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
3768         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
3769         except that we still need the overflow check!
3770
3771         Previously we mishandled this:
3772
3773         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
3774           to keep it alive. That's dirty and it's just indicative of a deeper issue.
3775
3776         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
3777           powerless. This was sort of hiding the bug.
3778
3779         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
3780           something that you are relying on for subsequent simplifications.
3781         
3782         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
3783         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
3784         we no longer need the weird MustGenerate node.
3785
3786         * dfg/DFGAbstractInterpreterInlines.h:
3787         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3788         * dfg/DFGArgumentsEliminationPhase.cpp:
3789         * dfg/DFGClobberize.h:
3790         (JSC::DFG::clobberize):
3791         * dfg/DFGDCEPhase.cpp:
3792         (JSC::DFG::DCEPhase::run):
3793         * dfg/DFGDoesGC.cpp:
3794         (JSC::DFG::doesGC):
3795         * dfg/DFGFixupPhase.cpp:
3796         (JSC::DFG::FixupPhase::fixupNode):
3797         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
3798         * dfg/DFGIntegerCheckCombiningPhase.cpp:
3799         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
3800         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
3801         * dfg/DFGMayExit.cpp:
3802         (JSC::DFG::mayExit):
3803         * dfg/DFGNode.h:
3804         (JSC::DFG::Node::willHaveCodeGenOrOSR):
3805         * dfg/DFGNodeType.h:
3806         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3807         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
3808         * dfg/DFGPhantomCanonicalizationPhase.cpp:
3809         (JSC::DFG::PhantomCanonicalizationPhase::run):
3810         * dfg/DFGPhantomRemovalPhase.cpp:
3811         (JSC::DFG::PhantomRemovalPhase::run):
3812         * dfg/DFGPlan.cpp:
3813         (JSC::DFG::Plan::compileInThreadImpl):
3814         * dfg/DFGPredictionPropagationPhase.cpp:
3815         (JSC::DFG::PredictionPropagationPhase::propagate):
3816         * dfg/DFGSafeToExecute.h:
3817         (JSC::DFG::safeToExecute):
3818         * dfg/DFGSpeculativeJIT32_64.cpp:
3819         (JSC::DFG::SpeculativeJIT::compile):
3820         * dfg/DFGSpeculativeJIT64.cpp:
3821         (JSC::DFG::SpeculativeJIT::compile):
3822         * dfg/DFGTypeCheckHoistingPhase.cpp:
3823         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
3824         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
3825         * dfg/DFGVarargsForwardingPhase.cpp:
3826         * ftl/FTLCapabilities.cpp:
3827         (JSC::FTL::canCompile):
3828         * ftl/FTLLowerDFGToLLVM.cpp:
3829         (JSC::FTL::LowerDFGToLLVM::compileNode):
3830         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
3831         (foo):
3832         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
3833         (foo):
3834         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
3835         (foo):
3836         * tests/stress/fold-based-on-int32-proof.js: Added.
3837         (foo):
3838
3839 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
3840
3841         Class body ending with a semicolon throws a SyntaxError
3842         https://bugs.webkit.org/show_bug.cgi?id=144244
3843
3844         Reviewed by Darin Adler.
3845
3846         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
3847         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
3848         it by continue'ing when it encounters a semicolon.
3849