FTL SwitchString slow case creates duplicate switch cases
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2
3         FTL SwitchString slow case creates duplicate switch cases
4         https://bugs.webkit.org/show_bug.cgi?id=144634
5
6         Reviewed by Geoffrey Garen.
7         
8         The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
9         added mostly-debug-only asserts to catch such issues earlier.
10
11         * bytecode/CallVariant.cpp:
12         (JSC::variantListWithVariant): Assertion to prevent similar bugs.
13         * ftl/FTLLowerDFGToLLVM.cpp:
14         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
15         (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
16         * jit/BinarySwitch.cpp:
17         (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
18         * jit/Repatch.cpp:
19         (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
20         * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
21         (foo):
22         (cat):
23
24 2015-05-05  Basile Clement  <basile_clement@apple.com>
25
26         Fix debug builds after r183812
27         https://bugs.webkit.org/show_bug.cgi?id=144300
28
29         Rubber stamped by Andreas Kling and Filip Pizlo.
30
31         hasObjectMaterializationData() didn't treat MaterializeCreateActivation
32         as having materialization data, which was causing an assertion failure when
33         sinking CreateActivations on debug builds.
34
35         * dfg/DFGNode.h:
36         (JSC::DFG::Node::hasObjectMaterializationData):
37
38 2015-05-04  Basile Clement  <basile_clement@apple.com>
39
40         Allow CreateActivation sinking
41         https://bugs.webkit.org/show_bug.cgi?id=144300
42
43         Reviewed by Filip Pizlo.
44
45         This pursues the work started in
46         https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
47         allocations we are able to sink by allowing sinking of CreateActivation
48         node.
49
50         This is achieved by following closely the way NewObject is currently
51         sunk: we add a new PhantomCreateActivation node to record the initial
52         position of the CreateActivation node, new ClosureVarPLoc promoted heap
53         locations to keep track of the variables put in the activation, and a
54         new MaterializeCreateActivation node to allocate and populate the sunk
55         activation.
56
57         * dfg/DFGAbstractInterpreterInlines.h:
58         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
59         * dfg/DFGClobberize.h:
60         (JSC::DFG::clobberize):
61         * dfg/DFGDoesGC.cpp:
62         (JSC::DFG::doesGC):
63         * dfg/DFGFixupPhase.cpp:
64         (JSC::DFG::FixupPhase::fixupNode):
65         * dfg/DFGNode.cpp:
66         (JSC::DFG::Node::convertToPutClosureVarHint):
67         * dfg/DFGNode.h:
68         (JSC::DFG::Node::convertToPhantomCreateActivation):
69         (JSC::DFG::Node::isActivationAllocation):
70         (JSC::DFG::Node::isPhantomActivationAllocation):
71         (JSC::DFG::Node::isPhantomAllocation):
72         * dfg/DFGNodeType.h:
73         * dfg/DFGObjectAllocationSinkingPhase.cpp:
74         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
75         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
76         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
77         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
78         * dfg/DFGPredictionPropagationPhase.cpp:
79         (JSC::DFG::PredictionPropagationPhase::propagate):
80         * dfg/DFGPromotedHeapLocation.cpp:
81         (WTF::printInternal):
82         * dfg/DFGPromotedHeapLocation.h:
83         * dfg/DFGSafeToExecute.h:
84         (JSC::DFG::safeToExecute):
85         * dfg/DFGSpeculativeJIT32_64.cpp:
86         (JSC::DFG::SpeculativeJIT::compile):
87         * dfg/DFGSpeculativeJIT64.cpp:
88         (JSC::DFG::SpeculativeJIT::compile):
89         * dfg/DFGValidate.cpp:
90         (JSC::DFG::Validate::validateCPS):
91         * ftl/FTLCapabilities.cpp:
92         (JSC::FTL::canCompile):
93         * ftl/FTLLowerDFGToLLVM.cpp:
94         (JSC::FTL::LowerDFGToLLVM::compileNode):
95         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
96         * ftl/FTLOperations.cpp:
97         (JSC::FTL::operationMaterializeObjectInOSR):
98         * tests/stress/activation-sink-osrexit.js: Added.
99         (bar):
100         (foo.set result):
101         * tests/stress/activation-sink.js: Added.
102         (bar):
103
104 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
105
106         Unreviewed, fix stale comment.
107
108         * tests/mozilla/js1_5/Array/regress-101964.js:
109
110 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
111
112         Large array shouldn't be slow
113         https://bugs.webkit.org/show_bug.cgi?id=144617
114
115         Rubber stamped by Mark Lam.
116
117         * 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.
118
119 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
120
121         Large array shouldn't be slow
122         https://bugs.webkit.org/show_bug.cgi?id=144617
123
124         Rubber stamped by Mark Lam.
125
126         * 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.
127
128 2015-05-04  Commit Queue  <commit-queue@webkit.org>
129
130         Unreviewed, rolling out r183789.
131         https://bugs.webkit.org/show_bug.cgi?id=144620
132
133         Causing flakiness on exceptionFuzz tests locally on 32-bit
134         build (Requested by saamyjoon on #webkit).
135
136         Reverted changeset:
137
138         "Global functions should be initialized as JSFunctions in byte
139         code"
140         https://bugs.webkit.org/show_bug.cgi?id=144178
141         http://trac.webkit.org/changeset/183789
142
143 2015-05-04  Saam Barati  <saambarati1@gmail.com>
144
145         Global functions should be initialized as JSFunctions in byte code
146         https://bugs.webkit.org/show_bug.cgi?id=144178
147
148         Reviewed by Geoffrey Garen.
149
150         This patch makes the initialization of global functions more explicit by
151         moving initialization into bytecode. It also prepares JSC for having ES6
152         style lexical scoping because initializing global functions in bytecode
153         easily allows global functions to be initialized with the proper scope that
154         will have access to global lexical variables. Global lexical variables
155         should be visible to global functions but don't live on the global object.
156
157         * bytecode/UnlinkedCodeBlock.cpp:
158         (JSC::UnlinkedProgramCodeBlock::visitChildren):
159         * bytecode/UnlinkedCodeBlock.h:
160         * bytecompiler/BytecodeGenerator.cpp:
161         (JSC::BytecodeGenerator::generate):
162         (JSC::BytecodeGenerator::BytecodeGenerator):
163         * bytecompiler/BytecodeGenerator.h:
164         * runtime/Executable.cpp:
165         (JSC::ProgramExecutable::initializeGlobalProperties):
166         * runtime/JSGlobalObject.cpp:
167         (JSC::JSGlobalObject::addGlobalVar):
168         (JSC::JSGlobalObject::addFunction):
169         * runtime/JSGlobalObject.h:
170
171 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
172
173         Large array shouldn't be slow
174         https://bugs.webkit.org/show_bug.cgi?id=144617
175
176         Reviewed by Geoffrey Garen.
177         
178         Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
179         you're already using ArrayStorage mode, from the minimul array length required to use
180         ArrayStorage in a new Array(length) allocation.
181         
182         Lift the array allocation length threshold to something very high. If this works, we'll
183         probably remove that threshold entirely.
184         
185         This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
186         JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
187         for now.
188
189         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
190         * dfg/DFGSpeculativeJIT32_64.cpp:
191         (JSC::DFG::SpeculativeJIT::compile):
192         * dfg/DFGSpeculativeJIT64.cpp:
193         (JSC::DFG::SpeculativeJIT::compile):
194         * ftl/FTLLowerDFGToLLVM.cpp:
195         (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
196         * runtime/ArrayConventions.h:
197         * runtime/JSArray.h:
198         (JSC::JSArray::create):
199         * runtime/JSGlobalObject.h:
200         (JSC::constructEmptyArray):
201         * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
202
203 2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
204
205         Add backed intrinsics to private functions exposed with private symbols in global object
206         https://bugs.webkit.org/show_bug.cgi?id=144545
207
208         Reviewed by Darin Adler.
209
210         Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
211         This patch adds intrinsic to private functions exposed with private symbols in global object,
212         @floor and @abs.
213
214         * runtime/JSGlobalObject.cpp:
215         (JSC::JSGlobalObject::init):
216         * runtime/JSGlobalObjectFunctions.cpp:
217         (JSC::globalPrivateFuncAbs): Deleted.
218         (JSC::globalPrivateFuncFloor): Deleted.
219         * runtime/MathObject.cpp:
220         * runtime/MathObject.h:
221         * tests/stress/array-from-abs-and-floor.js: Added.
222         (target1):
223         (target2):
224         (target3):
225
226 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
227
228         [cmake] ARM related build system cleanup
229         https://bugs.webkit.org/show_bug.cgi?id=144566
230
231         Reviewed by Darin Adler.
232
233         * CMakeLists.txt:
234
235 2015-05-04  Andreas Kling  <akling@apple.com>
236
237         Optimize WeakBlock's "reap" and "visit" operations.
238         <https://webkit.org/b/144585>
239
240         Reviewed by Geoffrey Garen.
241
242         WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
243         That function was really written with conservative roots marking in mind, and will do a bunch
244         of sanity and bounds checks.
245
246         For weaks, we know that the pointer will have been a valid cell pointer into a block
247         of appropriate cell size, so we can skip a lot of the checks.
248
249         We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
250         MarkedBlock::blockFor() for every single cell when iterating.
251
252         Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
253         WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
254         be pointing to any live cells, and the only operation that will run on the block is sweep().
255
256         Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
257         In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
258         This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
259
260         This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
261         what looks like a 1% speedup locally.
262
263         * heap/MarkedBlock.cpp:
264         (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
265
266         * heap/MarkedBlock.h:
267         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
268         block's state is known to be either Marked or Retired.
269
270         (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
271         would report that all cells are live anyway.
272
273         * heap/WeakBlock.cpp:
274         (JSC::WeakBlock::create):
275         (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
276
277         (JSC::WeakBlock::visit):
278         (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
279
280         * heap/WeakBlock.h:
281         (JSC::WeakBlock::disconnectMarkedBlock): Added.
282         * heap/WeakSet.cpp:
283         (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
284         ownership to Heap until it can die peacefully.
285
286         (JSC::WeakSet::addAllocator):
287         * heap/WeakSet.h:
288         (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
289
290 2015-05-04  Basile Clement  <basile_clement@apple.com>
291
292         Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
293         https://bugs.webkit.org/show_bug.cgi?id=144587
294
295         Rubber stamped by Filip Pizlo.
296
297         When sinking object allocations, we ensure in
298         determineMaterializationPoints that whenever an allocation is
299         materialized on a path to a block, it is materialized in all such
300         paths. Thus when running the SSA calculator to place Phis in
301         placeMaterializationPoints, we can't encounter a situation where some
302         Upsilons are referring to a materialization while others are referring
303         to the phantom object.
304
305         This replaces the code that was adding a materialization late in
306         placeMaterializationPoints to handle that case by an assertion that it
307         does not happen, which will make
308         https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
309
310         * dfg/DFGObjectAllocationSinkingPhase.cpp:
311         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
312
313 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
314
315         Extending undefined in class syntax should throw a TypeError
316         https://bugs.webkit.org/show_bug.cgi?id=144284
317
318         Reviewed by Darin Adler.
319
320         The bug was caused by op_eq_null evaluating to true when compared to undefined.
321         Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
322
323         We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
324
325         * bytecompiler/NodesCodegen.cpp:
326         (JSC::ClassExprNode::emitBytecode):
327
328 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
329
330         new super should be a syntax error
331         https://bugs.webkit.org/show_bug.cgi?id=144282
332
333         Reviewed by Joseph Pecoraro.
334
335         Disallow "new super" as ES6 spec doesn't allow this.
336
337         * parser/Parser.cpp:
338         (JSC::Parser<LexerType>::parseMemberExpression):
339
340 2015-05-04  Saam Barati  <saambarati1@gmail.com>
341
342         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
343         https://bugs.webkit.org/show_bug.cgi?id=144265
344
345         Reviewed by Geoffrey Garen.
346
347         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
348         for a static function if the parent has that property slot. JSCallbackObject::put 
349         did not maintain this symmetry of also calling ::put on the parent if the parent 
350         has the property. We should ensure that this symmetry exists.
351
352         * API/JSCallbackObjectFunctions.h:
353         (JSC::JSCallbackObject<Parent>::put):
354         * API/tests/testapi.c:
355         * API/tests/testapi.js:
356         (globalStaticFunction2):
357         (this.globalStaticFunction2):
358         (iAmNotAStaticFunction):
359         (this.iAmNotAStaticFunction):
360
361 2015-05-04  Andreas Kling  <akling@apple.com>
362
363         Make ExecState::vm() branchless in release builds.
364         <https://webkit.org/b/144586>
365
366         Reviewed by Geoffrey Garen.
367
368         Avoid null checking the ExecState's callee() before getting the
369         VM from it. The code was already dereferencing it anyway, since we
370         know it's not gonna be null.
371
372         * runtime/JSCellInlines.h:
373         (JSC::ExecState::vm):
374
375 2015-05-04  Basile Clement  <basile_clement@apple.com>
376
377         Object allocation not sinking properly through CheckStructure
378         https://bugs.webkit.org/show_bug.cgi?id=144465
379
380         Reviewed by Filip Pizlo.
381
382         Currently, sinking an allocation through a CheckStructure will
383         completely ignore all structure checking, which is obviously wrong.
384
385         A CheckStructureImmediate node type was present for that purpose, but
386         the CheckStructures were not properly replaced.  This ensures that
387         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
388         sunk through, and that structure checking happens correctly.
389
390         * dfg/DFGNode.h:
391         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
392         (JSC::DFG::Node::hasStructureSet):
393         * dfg/DFGObjectAllocationSinkingPhase.cpp:
394         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
395         * ftl/FTLLowerDFGToLLVM.cpp:
396         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
397         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
398         (JSC::FTL::LowerDFGToLLVM::checkStructure):
399         * tests/stress/sink_checkstructure.js: Added.
400         (foo):
401
402 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
403
404         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
405         https://bugs.webkit.org/show_bug.cgi?id=144476
406
407         Reviewed by Sam Weinig.
408
409         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
410
411         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
412         to my knowledge, the topic of how to optimize it is not covered in any
413         literature about sorting.
414
415         On the slowest jQuery sorting test -- prevAll -- our new
416         Array.prototype.sort, compared to its predecessor, performed 12% fewer
417         comparisons and requireed 10X less overhead per comparison. Yet, it was
418         slower.
419
420         It was slower because it inadvertantly increased the average cost of the
421         comparison function by 2X. jQuery uses compareDocumentPosition to compare
422         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
423         required to traverse backwards from b to a. In prevAll, we encounter the
424         worst case for merge sort of compareDocumentPosition: A long list of DOM
425         nodes in mostly reverse order. In this case, merge sort will sequentially
426         compareDocumentPosition(a, b), where a is not reachable backwards from
427         b, and therefore compareDocumentPosition will traverse the whole sibling
428         list.
429
430         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
431
432         This is a pretty silly thing to do, but it is harmless, and jQuery is
433         popular, so let's do it.
434
435         We do not risk suffering the same problem in reverse when sorting a long
436         list of DOM nodes in forward order. (We still have a 37% speedup on the
437         nextAll benchmark.) The reason is that merge sort performs 2X fewer
438         comparisons when the list is already sorted, so we can worry less about
439         the cost of each comparison.
440
441         A fully principled soultion to this problem would probably do something
442         like Python's timsort, which special-cases ordered ranges to perform
443         only O(n) comparisons. But that would contradict our original
444         goal of just having something simple that works.
445
446         Another option is for elements to keep a compareDocumentPosition cache,
447         like a node list cache, which allows you to determine the absolute
448         position of a node using a hash lookup. I will leave this as an exercise
449         for kling.
450
451         * builtins/Array.prototype.js:
452         (sort.merge): Compare in an order that is favorable to a comparator
453         that calls compareDocumentPosition.
454
455 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
456
457         [cmake] Fix generate-js-builtins related incremental build issue
458         https://bugs.webkit.org/show_bug.cgi?id=144094
459
460         Reviewed by Michael Saboff.
461
462         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
463         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
464         * DerivedSources.make:
465         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
466         * generate-js-builtins: Accept input files and input directory too.
467
468 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
469
470         Make some static data const
471         https://bugs.webkit.org/show_bug.cgi?id=144552
472
473         Reviewed by Andreas Kling.
474         
475         Turn characterSetInfo into const data.
476
477         * yarr/YarrCanonicalizeUCS2.cpp:
478         * yarr/YarrCanonicalizeUCS2.h:
479
480 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
481
482         TypeOf should be fast
483         https://bugs.webkit.org/show_bug.cgi?id=144396
484
485         Reviewed by Geoffrey Garen.
486         
487         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
488         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
489         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
490         
491         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
492         rely heavily on C++ calls to fulfill their function.
493         
494         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
495         
496         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
497         This means that if the TypeOf is dominated by any type checks, we will automatically prune
498         out cases that are redundant.
499         
500         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
501         code generation is designed to be reusable.
502         
503         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
504         the exotic call trap hook. That hook is now in a deeper slow path than before.
505
506         * CMakeLists.txt:
507         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
508         * JavaScriptCore.xcodeproj/project.pbxproj:
509         * dfg/DFGClobberize.h:
510         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
511         * dfg/DFGFixupPhase.cpp:
512         (JSC::DFG::FixupPhase::fixupNode):
513         * dfg/DFGHeapLocation.cpp:
514         (WTF::printInternal):
515         * dfg/DFGHeapLocation.h:
516         * dfg/DFGOperations.cpp:
517         * dfg/DFGOperations.h:
518         * dfg/DFGSpeculativeJIT.cpp:
519         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
520         (JSC::DFG::SpeculativeJIT::compileIsFunction):
521         (JSC::DFG::SpeculativeJIT::compileTypeOf):
522         * dfg/DFGSpeculativeJIT.h:
523         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
524         (JSC::DFG::SpeculativeJIT::callOperation):
525         * dfg/DFGSpeculativeJIT32_64.cpp:
526         (JSC::DFG::SpeculativeJIT::compile):
527         * dfg/DFGSpeculativeJIT64.cpp:
528         (JSC::DFG::SpeculativeJIT::compile):
529         * ftl/FTLCapabilities.cpp:
530         (JSC::FTL::canCompile):
531         * ftl/FTLIntrinsicRepository.h:
532         * ftl/FTLLowerDFGToLLVM.cpp:
533         (JSC::FTL::LowerDFGToLLVM::compileNode):
534         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
535         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
536         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
537         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
538         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
539         * ftl/FTLSwitchCase.h:
540         (JSC::FTL::SwitchCase::SwitchCase):
541         * jit/AssemblyHelpers.h:
542         (JSC::AssemblyHelpers::branchIfNotEqual):
543         (JSC::AssemblyHelpers::branchIfEqual):
544         (JSC::AssemblyHelpers::branchIfNumber):
545         (JSC::AssemblyHelpers::branchIfNotNumber):
546         (JSC::AssemblyHelpers::branchIfBoolean):
547         (JSC::AssemblyHelpers::branchIfNotBoolean):
548         (JSC::AssemblyHelpers::boxBooleanPayload):
549         (JSC::AssemblyHelpers::boxBoolean):
550         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
551         * jit/JITOperations.h:
552         * runtime/SmallStrings.h:
553         (JSC::SmallStrings::typeString):
554         * runtime/TypeofType.cpp: Added.
555         (WTF::printInternal):
556         * runtime/TypeofType.h: Added.
557         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
558
559 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
560
561         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
562
563         * dfg/DFGLICMPhase.cpp:
564         (JSC::DFG::LICMPhase::attemptHoist):
565
566 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
567
568         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
569         https://bugs.webkit.org/show_bug.cgi?id=144525.
570
571         * dfg/DFGLICMPhase.cpp:
572         (JSC::DFG::LICMPhase::attemptHoist):
573         * dfg/DFGPhantomInsertionPhase.cpp:
574
575 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
576
577         Static property hashtable should only lookup with non-symbol key
578         https://bugs.webkit.org/show_bug.cgi?id=144438
579
580         Reviewed by Darin Adler.
581
582         Static property hashtable compares the Identifier's uid
583         with the normal C string without interning it.
584         So this comparison is performed in their contents.
585         As the result, in this comparison, symbol-ness is not considered.
586
587         So if accidentally the hash collision occur with the symbol and the string
588         and they have the same contents, the hash table entry is looked up incorrectly.
589
590         * runtime/Lookup.h:
591         (JSC::HashTable::entry):
592
593 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
594
595         Class syntax should allow string and numeric identifiers for method names
596         https://bugs.webkit.org/show_bug.cgi?id=144254
597
598         Reviewed by Darin Adler.
599
600         Added the support for string and numeric identifiers in class syntax.
601
602         * parser/Parser.cpp:
603         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
604         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
605         outside a class constructor as it should be.
606         (JSC::Parser<LexerType>::parseFunctionDeclaration):
607         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
608         element to allow numeric and string method names. For both of those method names, parse it here instead
609         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
610         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
611         this function is never used to parse a class method.
612         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
613         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
614         * parser/Parser.h:
615         * parser/SyntaxChecker.h:
616         (JSC::SyntaxChecker::createProperty):
617
618 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
619
620         FTL should use AI more
621         https://bugs.webkit.org/show_bug.cgi?id=144500
622
623         Reviewed by Oliver Hunt.
624         
625         This makes our type check folding even more comprehensive by ensuring that even if the FTL
626         decides to emit some checks, it will still do another query to the abstract interpreter to
627         see if the check is necessary. This helps with cases where we decided early on to speculate
628         one way, but later proved a more specific type of the value in question, and the constant
629         folder didn't catch it.
630         
631         This also makes it more natural to query the abstract interpreter. For example, if you just
632         want the proven type, you can now say provenType(node) or provenType(edge).
633
634         * dfg/DFGArrayMode.cpp:
635         (JSC::DFG::ArrayMode::alreadyChecked):
636         * dfg/DFGArrayMode.h:
637         * ftl/FTLLowerDFGToLLVM.cpp:
638         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
639         (JSC::FTL::LowerDFGToLLVM::compileToThis):
640         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
641         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
642         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
643         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
644         (JSC::FTL::LowerDFGToLLVM::compileGetById):
645         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
646         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
647         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
648         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
649         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
650         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
651         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
652         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
653         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
654         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
655         (JSC::FTL::LowerDFGToLLVM::compileIsString):
656         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
657         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
658         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
659         (JSC::FTL::LowerDFGToLLVM::baseIndex):
660         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
661         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
662         (JSC::FTL::LowerDFGToLLVM::boolify):
663         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
664         (JSC::FTL::LowerDFGToLLVM::lowInt32):
665         (JSC::FTL::LowerDFGToLLVM::lowInt52):
666         (JSC::FTL::LowerDFGToLLVM::lowCell):
667         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
668         (JSC::FTL::LowerDFGToLLVM::lowDouble):
669         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
670         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
671         (JSC::FTL::LowerDFGToLLVM::isNumber):
672         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
673         (JSC::FTL::LowerDFGToLLVM::isNotCell):
674         (JSC::FTL::LowerDFGToLLVM::isCell):
675         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
676         (JSC::FTL::LowerDFGToLLVM::isMisc):
677         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
678         (JSC::FTL::LowerDFGToLLVM::isBoolean):
679         (JSC::FTL::LowerDFGToLLVM::isNotOther):
680         (JSC::FTL::LowerDFGToLLVM::isOther):
681         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
682         (JSC::FTL::LowerDFGToLLVM::isObject):
683         (JSC::FTL::LowerDFGToLLVM::isNotObject):
684         (JSC::FTL::LowerDFGToLLVM::isNotString):
685         (JSC::FTL::LowerDFGToLLVM::isString):
686         (JSC::FTL::LowerDFGToLLVM::isFunction):
687         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
688         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
689         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
690         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
691         (JSC::FTL::LowerDFGToLLVM::abstractValue):
692         (JSC::FTL::LowerDFGToLLVM::provenType):
693         (JSC::FTL::LowerDFGToLLVM::provenValue):
694         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
695
696 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
697
698         USE(...) macro should expect unprefixed variables
699         https://bugs.webkit.org/show_bug.cgi?id=144454
700
701         Reviewed by Daniel Bates.
702
703         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
704
705 2015-05-01  Jordan Harband  <ljharb@gmail.com>
706
707         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
708         https://bugs.webkit.org/show_bug.cgi?id=144314
709
710         Reviewed by Darin Adler.
711
712         Fixing handling of Infinity position args, per
713         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
714         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
715         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
716
717         * runtime/StringPrototype.cpp:
718         (JSC::clampInt32):
719         (JSC::stringProtoFuncStartsWith):
720         (JSC::stringProtoFuncEndsWith):
721         (JSC::stringProtoFuncIncludes):
722
723 2015-05-01  Basile Clement  <basile_clement@apple.com>
724
725         Math.abs() returns negative
726         https://bugs.webkit.org/show_bug.cgi?id=137827
727
728         Reviewed by Michael Saboff.
729
730         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
731         identity function.
732
733         * dfg/DFGAbstractInterpreterInlines.h:
734         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
735         * tests/stress/math-abs-positive.js: Added, was previously failing.
736         (foo):
737
738 2015-05-01  Basile Clement  <basile_clement@apple.com>
739
740         Function allocation sinking shouldn't be performed on singleton functions
741         https://bugs.webkit.org/show_bug.cgi?id=144166
742
743         Reviewed by Geoffrey Garen.
744
745         Function allocations usually are free of any other side effects, but
746         this is not the case for allocations performed while the underlying
747         FunctionExecutable is still a singleton (as this allogation will fire
748         watchpoints invalidating code that depends on it being a singleton).
749         As the object allocation sinking phase assumes object allocation is
750         free of side-effects, sinking these allocations is not correct.
751
752         This also means that when materializing a function allocation on OSR
753         exit, that function's executable will never be a singleton, and we don't have
754         to worry about its watchpoint, allowing us to use
755         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
756         JSFunction::create.
757
758         * dfg/DFGObjectAllocationSinkingPhase.cpp:
759         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
760         * ftl/FTLOperations.cpp:
761         (JSC::FTL::operationMaterializeObjectInOSR):
762
763 2015-04-30  Jon Davis  <jond@apple.com>
764
765         Web Inspector: console should show an icon for console.info() messages
766         https://bugs.webkit.org/show_bug.cgi?id=18530
767
768         Reviewed by Timothy Hatcher.
769
770         * inspector/ConsoleMessage.cpp:
771         (Inspector::messageLevelValue):
772         * inspector/protocol/Console.json:
773         * runtime/ConsoleClient.cpp:
774         (JSC::appendMessagePrefix):
775         * runtime/ConsolePrototype.cpp:
776         (JSC::ConsolePrototype::finishCreation):
777         (JSC::consoleProtoFuncInfo):
778         * runtime/ConsoleTypes.h:
779
780 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
781
782         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
783         https://bugs.webkit.org/show_bug.cgi?id=144462
784
785         Reviewed by Geoffrey Garen and Mark Lam.
786         
787         At some point we started adding representation-agnostic helpers for doing common type tests.
788         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
789         they had overlapping powers, though SpeculativeJIT was a bit better.
790         
791         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
792         better because now all of these helpers can be used in all of the assembly-based JITs, not
793         just the DFG. It also settles on what I find to be a slightly better naming convention.
794         For example where we previously would have said branchIsString, now we say
795         branchIfString. Similarly, branchNotString becomes branchIfNotString.
796
797         * dfg/DFGSpeculativeJIT.cpp:
798         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
799         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
800         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
801         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
802         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
803         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
804         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
805         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
806         (JSC::DFG::SpeculativeJIT::speculateObject):
807         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
808         (JSC::DFG::SpeculativeJIT::speculateString):
809         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
810         (JSC::DFG::SpeculativeJIT::speculateNotCell):
811         (JSC::DFG::SpeculativeJIT::speculateOther):
812         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
813         (JSC::DFG::SpeculativeJIT::emitSwitchString):
814         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
815         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
816         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
817         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
818         * dfg/DFGSpeculativeJIT.h:
819         * dfg/DFGSpeculativeJIT32_64.cpp:
820         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
821         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
822         (JSC::DFG::SpeculativeJIT::emitCall):
823         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
824         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
825         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
826         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
827         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
828         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
829         (JSC::DFG::SpeculativeJIT::compile):
830         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
831         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
832         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
833         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
834         * dfg/DFGSpeculativeJIT64.cpp:
835         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
836         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
837         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
838         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
839         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
840         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
841         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
842         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
843         (JSC::DFG::SpeculativeJIT::compile):
844         (JSC::DFG::SpeculativeJIT::writeBarrier):
845         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
846         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
847         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
848         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
849         * jit/AssemblyHelpers.h:
850         (JSC::AssemblyHelpers::branchIfCell):
851         (JSC::AssemblyHelpers::branchIfOther):
852         (JSC::AssemblyHelpers::branchIfNotOther):
853         (JSC::AssemblyHelpers::branchIfObject):
854         (JSC::AssemblyHelpers::branchIfNotObject):
855         (JSC::AssemblyHelpers::branchIfType):
856         (JSC::AssemblyHelpers::branchIfNotType):
857         (JSC::AssemblyHelpers::branchIfString):
858         (JSC::AssemblyHelpers::branchIfNotString):
859         (JSC::AssemblyHelpers::branchIfSymbol):
860         (JSC::AssemblyHelpers::branchIfNotSymbol):
861         (JSC::AssemblyHelpers::branchIfFunction):
862         (JSC::AssemblyHelpers::branchIfNotFunction):
863         (JSC::AssemblyHelpers::branchIfEmpty):
864         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
865         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
866         * jit/JITPropertyAccess.cpp:
867         (JSC::JIT::emitScopedArgumentsGetByVal):
868
869 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
870
871         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
872         https://bugs.webkit.org/show_bug.cgi?id=144463
873
874         Reviewed by Benjamin Poulain.
875         
876         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
877         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
878         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
879         converting the boolean into an integer. But as part of doing that, it would try to
880         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
881         and it would try to figure out if the addition might overflow. Part of that logic
882         involved checking if the immediate is either a boolean or a sufficiently small integer.
883         But: it would check if it's a sufficiently small integer before checking if it was a
884         boolean, so it would try to call asNumber() on the boolean.
885         
886         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
887         case was previously never hit until I wrote these tests, and so we never knew that
888         calling asNumber() on a boolean was wrong.
889         
890         The fix is super simple: the expression should just check for boolean first.
891         
892         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
893         garbage, and that's OK, since we'd take the boolean case anyway.
894
895         * dfg/DFGGraph.h:
896         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
897
898 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
899
900         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
901
902         * jit/JITOperations.cpp:
903
904 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
905
906         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
907         particular that they cannot change their minds and may be called from compiler threads.
908
909         Rubber stamped by Geoffrey Garen.
910
911         * runtime/JSCell.h:
912
913 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
914
915         DFG Is<Blah> versions of TypeOf should fold based on proven input type
916         https://bugs.webkit.org/show_bug.cgi?id=144409
917
918         Reviewed by Geoffrey Garen.
919         
920         We were missing some obvious folding opportunities here. I don't know how this affects real
921         code, but in general, we like to ensure that our constant folding is comprehensive. So this
922         is more about placating my static analysis OCD than anything else.
923         
924         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
925
926         * dfg/DFGAbstractInterpreterInlines.h:
927         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
928
929 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
930
931         Use the default hash value for Symbolized StringImpl
932         https://bugs.webkit.org/show_bug.cgi?id=144347
933
934         Reviewed by Darin Adler.
935
936         Before this patch, symbolized StringImpl* has a special hash value
937         to avoid the hash collision with the other normal StringImpl*.
938         I guess that it is introduced when private symbols are introduced.
939         However, it prevents using symbolized StringImpl* in the other place
940         For example, using it as WTFString cause a problem because of its special hash value.
941
942         When only using private symbols, they are not exposed to the outside of JSC,
943         so we can handle it carefully. But now, it's extended to symbols.
944         So I think storing a special hash value in StringImpl* causes an error.
945
946         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
947         And to provide significantly different hash value when using it as symbol,
948         store the additional hash value in symbolized StringImpl*. It is used when
949         the hash value is required by IdentifierRepHash.
950
951         * runtime/Identifier.h:
952         (JSC::IdentifierRepHash::hash):
953         * runtime/Lookup.h:
954         (JSC::HashTable::entry):
955         * runtime/PropertyMapHashTable.h:
956         (JSC::PropertyTable::find):
957         (JSC::PropertyTable::get):
958         * runtime/Structure.cpp:
959         (JSC::PropertyTable::checkConsistency):
960
961 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
962
963         [JSC] Remove RageConvert array conversion
964         https://bugs.webkit.org/show_bug.cgi?id=144433
965
966         Reviewed by Filip Pizlo.
967
968         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
969         pretty hard:
970         -The indexing types shows that the array access varies between Int32 and DoubleArray.
971         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
972          An Arrayify node would convert the Int32 to that type.
973         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
974          node would use RageConvert instead of Convert.
975         -The Arrayify for that GetByVal with RageConvert would not convert the array to
976          Contiguous.
977         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
978          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
979          fail systematically and we never get to run the later code.
980
981         Getting rid of RageConvert fixes the problem and does not seems to have any
982         negative side effect on other benchmarks.
983
984         The improvments on Kraken are:
985             -stanford-crypto-aes: definitely 1.0915x faster.
986             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
987             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
988
989         * dfg/DFGAbstractInterpreterInlines.h:
990         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
991         * dfg/DFGArrayMode.cpp:
992         (JSC::DFG::ArrayMode::refine):
993         (JSC::DFG::arrayConversionToString):
994         * dfg/DFGArrayMode.h:
995         * dfg/DFGArrayifySlowPathGenerator.h:
996         * dfg/DFGFixupPhase.cpp:
997         (JSC::DFG::FixupPhase::fixupNode):
998         * dfg/DFGOperations.cpp:
999         * dfg/DFGOperations.h:
1000         * dfg/DFGPredictionPropagationPhase.cpp:
1001         (JSC::DFG::PredictionPropagationPhase::propagate):
1002         * dfg/DFGTypeCheckHoistingPhase.cpp:
1003         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1004         * ftl/FTLLowerDFGToLLVM.cpp:
1005         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
1006         * runtime/JSObject.cpp:
1007         (JSC::JSObject::convertDoubleToContiguous):
1008         (JSC::JSObject::ensureContiguousSlow):
1009         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
1010         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
1011         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
1012         * runtime/JSObject.h:
1013         (JSC::JSObject::rageEnsureContiguous): Deleted.
1014
1015 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
1016
1017         Gracefully handle missing auto pause key on remote inspector setup
1018         https://bugs.webkit.org/show_bug.cgi?id=144411
1019
1020         Reviewed by Timothy Hatcher.
1021
1022         * inspector/remote/RemoteInspector.mm:
1023         (Inspector::RemoteInspector::receivedSetupMessage):
1024
1025 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
1026
1027         NodeList has issues with Symbol and empty string
1028         https://bugs.webkit.org/show_bug.cgi?id=144310
1029
1030         Reviewed by Darin Adler.
1031
1032         * runtime/PropertyName.h:
1033         (JSC::PropertyName::isSymbol):
1034         Helper to check if the PropertyName is a string or symbol property.
1035
1036 2015-04-29  Alex Christensen  <achristensen@webkit.org>
1037
1038         Fix non-cygwin incremental builds on Windows.
1039         https://bugs.webkit.org/show_bug.cgi?id=143264
1040
1041         Reviewed by Brent Fulgham.
1042
1043         * generate-js-builtins:
1044         Remove stale headers before calling os.rename to replace them.
1045
1046 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
1047
1048         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
1049         https://bugs.webkit.org/show_bug.cgi?id=144397
1050
1051         Reviewed by Andreas Kling.
1052         
1053         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
1054         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
1055         making a getCallData() call if it isn't necessary.
1056
1057         * API/JSCallbackObject.h:
1058         * runtime/InternalFunction.h:
1059         * runtime/JSTypeInfo.h:
1060         (JSC::TypeInfo::typeOfShouldCallGetCallData):
1061         * runtime/Operations.cpp:
1062         (JSC::jsTypeStringForValue):
1063         * tests/stress/type-of-functions-and-objects.js: Added.
1064         (foo):
1065         (bar):
1066         (baz):
1067         (fuzz):
1068         (expect):
1069         (test):
1070
1071 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
1072
1073         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
1074         https://bugs.webkit.org/show_bug.cgi?id=144013
1075
1076         Reviewed by Mark Lam.
1077
1078         This patch implements Array.prototype.sort in JavaScript, removing the
1079         C++ implementations. It is simpler and less error-prone to express our
1080         operations in JavaScript, which provides memory safety, exception safety,
1081         and recursion safety.
1082
1083         The performance result is mixed, but net positive in my opinion. It's
1084         difficult to enumerate all the results, since we used to have so many
1085         different sorting modes, and there are lots of different data patterns
1086         across which you might want to measure sorting. Suffice it to say:
1087
1088             (*) The benchmarks we track are faster or unchanged.
1089
1090             (*) Sorting random input using a comparator -- which we think is
1091             common -- is 3X faster.
1092
1093             (*) Sorting random input in a non-array object -- which jQuery does
1094             -- is 4X faster.
1095
1096             (*) Sorting random input in a compact array of integers using a
1097             trivial pattern-matchable comparator is 2X *slower*.
1098
1099         * builtins/Array.prototype.js:
1100         (sort.min):
1101         (sort.stringComparator):
1102         (sort.compactSparse): Special case compaction for sparse arrays because
1103         we don't want to hang when sorting new Array(BIG).
1104
1105         (sort.compact):
1106         (sort.merge):
1107         (sort.mergeSort): Use merge sort because it's a reasonably efficient
1108         stable sort. We have evidence that some sites depend on stable sort,
1109         even though the ES6 spec does not mandate it. (See
1110         <http://trac.webkit.org/changeset/33967>.)
1111
1112         This is a textbook implementation of merge sort with three optimizations:
1113
1114             (1) Use iteration instead of recursion;
1115
1116             (2) Use array subscripting instead of array copying in order to
1117             create logical sub-lists without creating physical sub-lists;
1118
1119             (3) Swap src and dst at each iteration instead of copying src into
1120             dst, and only copy src into the subject array at the end if src is
1121             not the subject array.
1122
1123         (sort.inflate):
1124         (sort.comparatorSort):
1125         (sort): Sort in JavaScript for the win.
1126
1127         * builtins/BuiltinExecutables.cpp:
1128         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
1129         names so we can use helper functions.
1130
1131         * bytecode/CodeBlock.h:
1132         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
1133         * bytecode/UnlinkedCodeBlock.cpp:
1134         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1135         * bytecode/UnlinkedCodeBlock.h:
1136         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
1137         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
1138         * bytecompiler/BytecodeGenerator.cpp:
1139         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
1140         * bytecompiler/BytecodeGenerator.h:
1141         * bytecompiler/NodesCodegen.cpp:
1142         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
1143         on pattern matching anymore. This was mainly an optimization to avoid 
1144         the overhead of calling from C++ to JS, which we now avoid by
1145         sorting in JS.
1146
1147         * heap/Heap.cpp:
1148         (JSC::Heap::markRoots):
1149         (JSC::Heap::pushTempSortVector): Deleted.
1150         (JSC::Heap::popTempSortVector): Deleted.
1151         (JSC::Heap::visitTempSortVectors): Deleted.
1152         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
1153         in JavaScript using a normal JavaScript array for our temporary storage.
1154
1155         * parser/Parser.cpp:
1156         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
1157         helper functions.
1158
1159         * runtime/ArrayPrototype.cpp:
1160         (JSC::isNumericCompareFunction): Deleted.
1161         (JSC::attemptFastSort): Deleted.
1162         (JSC::performSlowSort): Deleted.
1163         (JSC::arrayProtoFuncSort): Deleted.
1164
1165         * runtime/CommonIdentifiers.h: New strings used by sort.
1166
1167         * runtime/JSArray.cpp:
1168         (JSC::compareNumbersForQSortWithInt32): Deleted.
1169         (JSC::compareNumbersForQSortWithDouble): Deleted.
1170         (JSC::compareNumbersForQSort): Deleted.
1171         (JSC::compareByStringPairForQSort): Deleted.
1172         (JSC::JSArray::sortNumericVector): Deleted.
1173         (JSC::JSArray::sortNumeric): Deleted.
1174         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
1175         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
1176         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
1177         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
1178         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
1179         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
1180         (JSC::JSArray::sortCompactedVector): Deleted.
1181         (JSC::JSArray::sort): Deleted.
1182         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
1183         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
1184         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
1185         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
1186         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
1187         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
1188         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
1189         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
1190         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
1191         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
1192         (JSC::JSArray::sortVector): Deleted.
1193         (JSC::JSArray::compactForSorting): Deleted.
1194         * runtime/JSArray.h:
1195
1196         * runtime/JSGlobalObject.cpp:
1197         (JSC::JSGlobalObject::init):
1198         * runtime/ObjectConstructor.cpp:
1199         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
1200         by sort.
1201
1202 2015-04-29  Mark Lam  <mark.lam@apple.com>
1203
1204         Safari WebKit crash when loading Google Spreadsheet.
1205         https://bugs.webkit.org/show_bug.cgi?id=144020
1206
1207         Reviewed by Filip Pizlo.
1208
1209         The bug is that the object allocation sinking phase did not account for a case
1210         where a property of a sunken object is only initialized on one path and not
1211         another.  As a result, on the path where the property is not initialized, we'll
1212         encounter an Upsilon with a BottomValue (which is not allowed by definition).
1213
1214         The fix is to use a JSConstant(undefined) as the bottom value instead (of
1215         BottomValue).  If the property is uninitialized, it should still be accessible
1216         and have the value undefined.
1217
1218         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1219         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
1220         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
1221         (foo):
1222         (foo2):
1223
1224 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
1225
1226         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1227         https://bugs.webkit.org/show_bug.cgi?id=144257
1228
1229         Reviewed by Darin Adler.
1230
1231         SHA1 is used to calculate CodeBlockHash.
1232         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
1233         However, the source code can contain null character.
1234         So when performing `strlen` on the source code's CString, it returns the incorrect length.
1235         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
1236
1237         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
1238         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
1239
1240         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
1241         is not correct. Because
1242
1243         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
1244         2. If CString can contain a null character, this assertion becomes incorrect.
1245
1246         So this patch just drops the assertion.
1247
1248         In the current implementation, we once convert the entire source code to the newly allocated
1249         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
1250         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
1251         We'll implement it in the separate patch[2].
1252
1253         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
1254         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
1255
1256         * tests/stress/eval-script-contains-null-character.js: Added.
1257         (shouldBe):
1258         (test):
1259         * tests/stress/template-literal-line-terminators.js:
1260         * tests/stress/template-literal-syntax.js:
1261         * tests/stress/template-literal.js:
1262
1263 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
1264
1265         Evict IsEnvironmentRecord from inline type flags
1266         https://bugs.webkit.org/show_bug.cgi?id=144398
1267
1268         Reviewed by Mark Lam and Michael Saboff.
1269         
1270         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
1271         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
1272         and evicts it into the out-of-line type flags. This change has no performance implications
1273         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
1274         where we access it at all is in String.prototype.repeat, and there we already load the
1275         structure anyway.
1276
1277         * runtime/JSTypeInfo.h:
1278         (JSC::TypeInfo::implementsHasInstance):
1279         (JSC::TypeInfo::structureIsImmortal):
1280         (JSC::TypeInfo::isEnvironmentRecord):
1281
1282 2015-04-29  Darin Adler  <darin@apple.com>
1283
1284         [ES6] Implement Unicode code point escapes
1285         https://bugs.webkit.org/show_bug.cgi?id=144377
1286
1287         Reviewed by Antti Koivisto.
1288
1289         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
1290         the header. Made it a non-member class so it doesn't need to be part
1291         of a template. Made it use UChar32 instead of int for the value to
1292         make it clearer what goes into this class.
1293         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
1294         old type() function.
1295         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
1296         parseFourDigitUnicodeHex and added support for code point escapes.
1297         (JSC::isLatin1): Added an overload for UChar32.
1298         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
1299         to call it with a UChar, so no need to overload for that type for now.
1300         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
1301         Also added FIXME about a subtle ES6 change that we might want to make later.
1302         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
1303         to call it with a UChar, so no need to overload for that type for now.
1304         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
1305         don't need to repeat the code twice. Added code to handle code point escapes.
1306         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
1307         code in line.
1308         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
1309         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
1310         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
1311         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
1312         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
1313         the code that handles the escapes, since the code point escape code now
1314         consumes characters while parsing rather than peeking ahead. Test case
1315         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
1316         giving a syntax error.
1317
1318         * parser/Lexer.h: Updated for above changes.
1319
1320         * runtime/StringConstructor.cpp:
1321         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
1322         out 0x10FFFF; clearer this way.
1323
1324 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
1325
1326         [CMake] [GTK] Organize and clean up unused CMake variables
1327         https://bugs.webkit.org/show_bug.cgi?id=144364
1328
1329         Reviewed by Gyuyoung Kim.
1330
1331         * PlatformGTK.cmake: Add variables specific to this project.
1332
1333 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1334
1335         TypeOf should return SpecStringIdent and the DFG should know this
1336         https://bugs.webkit.org/show_bug.cgi?id=144376
1337
1338         Reviewed by Andreas Kling.
1339         
1340         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
1341         
1342         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
1343         bad.
1344
1345         * dfg/DFGAbstractInterpreterInlines.h:
1346         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1347         * dfg/DFGAbstractValue.cpp:
1348         (JSC::DFG::AbstractValue::setType):
1349         * dfg/DFGAbstractValue.h:
1350         (JSC::DFG::AbstractValue::setType):
1351         * dfg/DFGInPlaceAbstractState.cpp:
1352         (JSC::DFG::InPlaceAbstractState::initialize):
1353         * dfg/DFGPredictionPropagationPhase.cpp:
1354         (JSC::DFG::PredictionPropagationPhase::propagate):
1355         * runtime/SmallStrings.cpp:
1356         (JSC::SmallStrings::initialize):
1357         * tests/stress/switch-typeof-indirect.js: Added.
1358         (bar):
1359         (foo):
1360         (test):
1361         * tests/stress/switch-typeof-slightly-indirect.js: Added.
1362         (foo):
1363         (test):
1364         * tests/stress/switch-typeof.js: Added.
1365         (foo):
1366         (test):
1367
1368 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
1369
1370         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
1371         https://bugs.webkit.org/show_bug.cgi?id=144373
1372
1373         Reviewed by Darin Adler.
1374
1375         Revert r181868 as it caused a failure on live.com. We can try
1376         re-enabling this exception after we make idl attributes configurable,
1377         which may have prevented this particular failure.
1378
1379         * runtime/ObjectPrototype.cpp:
1380         (JSC::objectProtoFuncDefineGetter):
1381         (JSC::objectProtoFuncDefineSetter):
1382
1383 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1384
1385         Deadlock on applications using JSContext on non-main thread
1386         https://bugs.webkit.org/show_bug.cgi?id=144370
1387
1388         Reviewed by Timothy Hatcher.
1389
1390         * inspector/remote/RemoteInspector.mm:
1391         (Inspector::RemoteInspector::singleton):
1392         Prevent a possible deadlock by assuming we can synchronously
1393         run something on the main queue at this time.
1394
1395 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1396
1397         FTL should fully support Switch (it currently lacks the SwitchString variant)
1398         https://bugs.webkit.org/show_bug.cgi?id=144348
1399
1400         Reviewed by Benjamin Poulain.
1401         
1402         This adds SwitchString support to the FTL. This is already tested by switch microbenchmarks
1403         in LayoutTests/js/regress.
1404
1405         * dfg/DFGCommon.cpp:
1406         (JSC::DFG::stringLessThan):
1407         * dfg/DFGCommon.h:
1408         * dfg/DFGOperations.cpp:
1409         * dfg/DFGOperations.h:
1410         * dfg/DFGSpeculativeJIT.cpp:
1411         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<): Deleted.
1412         * dfg/DFGSpeculativeJIT.h:
1413         (JSC::DFG::SpeculativeJIT::StringSwitchCase::operator<):
1414         * ftl/FTLCapabilities.cpp:
1415         (JSC::FTL::canCompile):
1416         * ftl/FTLIntrinsicRepository.h:
1417         * ftl/FTLLowerDFGToLLVM.cpp:
1418         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
1419         (JSC::FTL::LowerDFGToLLVM::switchString):
1420         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::StringSwitchCase):
1421         (JSC::FTL::LowerDFGToLLVM::StringSwitchCase::operator<):
1422         (JSC::FTL::LowerDFGToLLVM::CharacterCase::CharacterCase):
1423         (JSC::FTL::LowerDFGToLLVM::CharacterCase::operator<):
1424         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse):
1425         (JSC::FTL::LowerDFGToLLVM::switchStringSlow):
1426         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1427         * ftl/FTLOutput.cpp:
1428         (JSC::FTL::Output::check):
1429         * ftl/FTLOutput.h:
1430         * ftl/FTLWeight.h:
1431         (JSC::FTL::Weight::inverse):
1432         * jit/JITOperations.h:
1433
1434 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1435
1436         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1437         https://bugs.webkit.org/show_bug.cgi?id=144304
1438
1439         Reviewed by Geoffrey Garen.
1440
1441         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1442         ENABLE_LLINT_C_LOOP, disabled by default.
1443         * llint/LLIntSlowPaths.cpp:
1444         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1445
1446 2015-04-28  Commit Queue  <commit-queue@webkit.org>
1447
1448         Unreviewed, rolling out r183514.
1449         https://bugs.webkit.org/show_bug.cgi?id=144359
1450
1451         It broke cloop test bots (Requested by mcatanzaro on #webkit).
1452
1453         Reverted changeset:
1454
1455         "Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT"
1456         https://bugs.webkit.org/show_bug.cgi?id=144304
1457         http://trac.webkit.org/changeset/183514
1458
1459 2015-04-28  Michael Catanzaro  <mcatanzaro@igalia.com>
1460
1461         Fully replace ENABLE_LLINT_C_LOOP with ENABLE_JIT
1462         https://bugs.webkit.org/show_bug.cgi?id=144304
1463
1464         Reviewed by Geoffrey Garen.
1465
1466         * Configurations/FeatureDefines.xcconfig: Define ENABLE_JIT, enabled by default, instead of
1467         ENABLE_LLINT_C_LOOP, disabled by default.
1468         * llint/LLIntSlowPaths.cpp:
1469         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Check ENABLE_JIT instead of ENABLE_LLINT_C_LOOP.
1470
1471 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1472
1473         Fix common typo "targetting" => "targeting"
1474         https://bugs.webkit.org/show_bug.cgi?id=144349
1475
1476         Reviewed by Daniel Bates.
1477
1478         * bytecode/ExecutionCounter.h:
1479
1480 2015-04-28  Yusuke Suzuki  <utatane.tea@gmail.com>
1481
1482         Update the features.json for WeakSet, WeakMap, Template literals, Tagged templates
1483         https://bugs.webkit.org/show_bug.cgi?id=144328
1484
1485         Reviewed by Andreas Kling.
1486
1487         Update the status of ES6 features.
1488
1489         * features.json:
1490
1491 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1492
1493         DFG should not use or preserve Phantoms during transformations
1494         https://bugs.webkit.org/show_bug.cgi?id=143736
1495
1496         Reviewed by Geoffrey Garen.
1497         
1498         Since http://trac.webkit.org/changeset/183207 and http://trac.webkit.org/changeset/183406, it is
1499         no longer necessary to preserve Phantoms during transformations. They are still useful just
1500         before FixupPhase to support backwards propagation analyses. They are still inserted late in the
1501         game in the DFG backend. But transformations don't need to worry about them. Inside a basic
1502         block, we can be sure that so long as the IR pinpoints the place where the value becomes
1503         available in a bytecode register (using MovHint) and so long as there is a SetLocal anytime some
1504         other block would need the value (either for OSR or for DFG execution), then we don't need any
1505         liveness markers.
1506         
1507         So, this removes any places where we inserted Phantoms just for liveness during transformation
1508         and it replaces convertToPhantom() with remove(), which just converts the node to a Check. A
1509         Check node only keeps its children so long as those children have checks.
1510         
1511         The fact that we no longer convertToPhantom() means that we have to be more careful when
1512         constant-folding GetLocal. Previously we would convertToPhantom() and use the fact that
1513         Phantom(Phi) was a valid construct. It's not valid anymore. So, when constant folding encounters
1514         a GetLocal it needs to insert a PhantomLocal directly. This allows us to simplify
1515         Graph::convertToConstant() a bit. Luckily, none of the other users of this method would see
1516         GetLocals.
1517         
1518         The only Phantom-like cruft left over after this patch is:
1519         
1520         - Phantoms before FixupPhase. I kind of like these. It means that before FixupPhase, we can do
1521           backwards analyses and rely on the fact that the users of a node in DFG IR are a superset of
1522           the users of the original local's live range in bytecode. This is essential for supporting our
1523           BackwardsPropagationPhase, which is an important optimization for things like asm.js.
1524         
1525         - PhantomLocals and GetLocals being NodeMustGenerate. See discussion in
1526           https://bugs.webkit.org/show_bug.cgi?id=144086. It appears that this is not as evil as the
1527           alternatives. The best long-term plan is to simply ditch the ThreadedCPS IR entirely and have
1528           the DFG use SSA. For now, so long as any new DFG optimizations we add are block-local and
1529           treat GetLocal/SetLocal conservatively, this should all be sound.
1530         
1531         This change should be perf-neutral although it does reduce the total work that the compiler
1532         does.
1533
1534         * CMakeLists.txt:
1535         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1536         * JavaScriptCore.xcodeproj/project.pbxproj:
1537         * dfg/DFGAdjacencyList.h:
1538         (JSC::DFG::AdjacencyList::justChecks):
1539         * dfg/DFGArgumentsEliminationPhase.cpp:
1540         * dfg/DFGBasicBlock.cpp:
1541         (JSC::DFG::BasicBlock::replaceTerminal):
1542         * dfg/DFGBasicBlock.h:
1543         (JSC::DFG::BasicBlock::findTerminal):
1544         * dfg/DFGCFGSimplificationPhase.cpp:
1545         (JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
1546         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1547         * dfg/DFGCPSRethreadingPhase.cpp:
1548         (JSC::DFG::CPSRethreadingPhase::CPSRethreadingPhase):
1549         (JSC::DFG::CPSRethreadingPhase::clearVariables):
1550         (JSC::DFG::CPSRethreadingPhase::canonicalizeFlushOrPhantomLocalFor):
1551         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1552         * dfg/DFGCSEPhase.cpp:
1553         * dfg/DFGCleanUpPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.cpp.
1554         (JSC::DFG::CleanUpPhase::CleanUpPhase):
1555         (JSC::DFG::CleanUpPhase::run):
1556         (JSC::DFG::performCleanUp):
1557         (JSC::DFG::PhantomRemovalPhase::PhantomRemovalPhase): Deleted.
1558         (JSC::DFG::PhantomRemovalPhase::run): Deleted.
1559         (JSC::DFG::performPhantomRemoval): Deleted.
1560         * dfg/DFGCleanUpPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPhantomRemovalPhase.h.
1561         * dfg/DFGConstantFoldingPhase.cpp:
1562         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1563         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
1564         (JSC::DFG::ConstantFoldingPhase::fixUpsilons):
1565         * dfg/DFGDCEPhase.cpp:
1566         (JSC::DFG::DCEPhase::run):
1567         (JSC::DFG::DCEPhase::fixupBlock):
1568         (JSC::DFG::DCEPhase::cleanVariables):
1569         * dfg/DFGFixupPhase.cpp:
1570         (JSC::DFG::FixupPhase::fixupBlock):
1571         (JSC::DFG::FixupPhase::fixupNode):
1572         (JSC::DFG::FixupPhase::convertStringAddUse):
1573         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1574         (JSC::DFG::FixupPhase::checkArray):
1575         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
1576         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
1577         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
1578         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
1579         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1580         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge):
1581         (JSC::DFG::FixupPhase::addRequiredPhantom): Deleted.
1582         (JSC::DFG::FixupPhase::addPhantomsIfNecessary): Deleted.
1583         * dfg/DFGGraph.cpp:
1584         (JSC::DFG::Graph::convertToConstant):
1585         (JSC::DFG::Graph::mergeRelevantToOSR): Deleted.
1586         * dfg/DFGGraph.h:
1587         * dfg/DFGInsertionSet.h:
1588         (JSC::DFG::InsertionSet::insertCheck):
1589         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1590         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1591         * dfg/DFGLICMPhase.cpp:
1592         (JSC::DFG::LICMPhase::attemptHoist):
1593         * dfg/DFGNode.cpp:
1594         (JSC::DFG::Node::remove):
1595         * dfg/DFGNode.h:
1596         (JSC::DFG::Node::replaceWith):
1597         (JSC::DFG::Node::convertToPhantom): Deleted.
1598         (JSC::DFG::Node::convertToCheck): Deleted.
1599         (JSC::DFG::Node::willHaveCodeGenOrOSR): Deleted.
1600         * dfg/DFGNodeFlags.h:
1601         * dfg/DFGNodeType.h:
1602         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1603         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1604         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1605         * dfg/DFGPhantomCanonicalizationPhase.cpp: Removed.
1606         * dfg/DFGPhantomCanonicalizationPhase.h: Removed.
1607         * dfg/DFGPhantomRemovalPhase.cpp: Removed.
1608         * dfg/DFGPhantomRemovalPhase.h: Removed.
1609         * dfg/DFGPlan.cpp:
1610         (JSC::DFG::Plan::compileInThreadImpl):
1611         * dfg/DFGPutStackSinkingPhase.cpp:
1612         * dfg/DFGResurrectionForValidationPhase.cpp: Removed.
1613         * dfg/DFGResurrectionForValidationPhase.h: Removed.
1614         * dfg/DFGSSAConversionPhase.cpp:
1615         (JSC::DFG::SSAConversionPhase::run):
1616         * dfg/DFGSpeculativeJIT64.cpp:
1617         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
1618         * dfg/DFGStoreBarrierElisionPhase.cpp:
1619         (JSC::DFG::StoreBarrierElisionPhase::elideBarrier):
1620         * dfg/DFGStrengthReductionPhase.cpp:
1621         (JSC::DFG::StrengthReductionPhase::handleNode):
1622         (JSC::DFG::StrengthReductionPhase::convertToIdentityOverChild):
1623         * dfg/DFGValidate.cpp:
1624         (JSC::DFG::Validate::validate):
1625         (JSC::DFG::Validate::validateCPS):
1626         (JSC::DFG::Validate::validateSSA):
1627         * dfg/DFGVarargsForwardingPhase.cpp:
1628         * ftl/FTLLink.cpp:
1629         (JSC::FTL::link):
1630         * ftl/FTLLowerDFGToLLVM.cpp:
1631         (JSC::FTL::LowerDFGToLLVM::compileNode):
1632         (JSC::FTL::LowerDFGToLLVM::compileNoOp):
1633         (JSC::FTL::LowerDFGToLLVM::compilePhantom): Deleted.
1634
1635 2015-04-28  Andreas Kling  <akling@apple.com>
1636
1637         DFG+FTL should generate efficient code for branching on a string's boolean value.
1638         <https://webkit.org/b/144317>
1639
1640         Reviewed by Geoff Garen & Filip Pizlo
1641
1642         Teach Branch nodes about StringUse and have them generate an efficient zero-length string check
1643         instead of dropping out to C++ whenever we branch on a string.
1644
1645         The FTL JIT already handled Branch nodes with StringUse through its use of boolify(), so only
1646         the DFG JIT gets some new codegen logic in this patch.
1647
1648         Test: js/regress/branch-on-string-as-boolean.js (~4.5x speedup)
1649
1650         * dfg/DFGFixupPhase.cpp:
1651         (JSC::DFG::FixupPhase::fixupNode):
1652         * dfg/DFGSpeculativeJIT.cpp:
1653         (JSC::DFG::SpeculativeJIT::emitStringBranch):
1654         * dfg/DFGSpeculativeJIT.h:
1655         * dfg/DFGSpeculativeJIT32_64.cpp:
1656         (JSC::DFG::SpeculativeJIT::emitBranch):
1657         * dfg/DFGSpeculativeJIT64.cpp:
1658         (JSC::DFG::SpeculativeJIT::emitBranch):
1659
1660 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
1661
1662         VarargsForwardingPhase should only consider MovHints that have the candidate as a child
1663         https://bugs.webkit.org/show_bug.cgi?id=144340
1664
1665         Reviewed by Michael Saboff and Mark Lam.
1666         
1667         Since we were considering all MovHints, we'd assume that the CreateDirectArguments or
1668         CreateClosedArguments node was live so long as any MovHinted bytecode variable was alive.
1669         Basically, we'd keep it alive until the end of the block. This maximized the chances of
1670         there being an interfering operation, which would prevent elimination.
1671         
1672         The fix is to only consider MovHints that have the arguments candidate as a child. We only
1673         care to track the liveness of those bytecode locals that would need an arguments object
1674         recovery on OSR exit.
1675         
1676         This is a speed-up on V8Spider/raytrace and Octane/raytrace because it undoes the regression
1677         introduced in http://trac.webkit.org/changeset/183406.
1678
1679         * dfg/DFGVarargsForwardingPhase.cpp:
1680
1681 2015-04-28  Csaba Osztrogonác  <ossy@webkit.org>
1682
1683         Remove WinCE cruft from cmake build system
1684         https://bugs.webkit.org/show_bug.cgi?id=144325
1685
1686         Reviewed by Gyuyoung Kim.
1687
1688         * CMakeLists.txt:
1689         * create_jit_stubs: Removed.
1690
1691 2015-04-27  Andreas Kling  <akling@apple.com>
1692
1693         RegExp matches arrays should use contiguous indexing.
1694         <https://webkit.org/b/144286>
1695
1696         Reviewed by Geoffrey Garen.
1697
1698         We had a custom Structure being used for RegExp matches arrays that would
1699         put the arrays into SlowPutArrayStorageShape mode. This was just left
1700         from when matches arrays were custom, lazily initialized objects.
1701
1702         This change removes that Structure and switches the matches arrays to
1703         using the default ContiguousShape Structure. This allows the FTL JIT
1704         to compile the inner loop of the Octane/regexp benchmark.
1705
1706         Also made a version of initializeIndex() [inline] that takes the indexing
1707         type in an argument, allowing createRegExpMatchesArray() to initialize
1708         the entire array without branching on the indexing type for each entry.
1709
1710         ~3% progression on Octane/regexp.
1711
1712         * runtime/JSGlobalObject.cpp:
1713         (JSC::JSGlobalObject::init):
1714         (JSC::JSGlobalObject::visitChildren):
1715         * runtime/JSGlobalObject.h:
1716         (JSC::JSGlobalObject::mapStructure):
1717         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1718         * runtime/JSObject.h:
1719         (JSC::JSObject::initializeIndex):
1720         * runtime/RegExpMatchesArray.cpp:
1721         (JSC::createRegExpMatchesArray):
1722
1723 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1724
1725         FTL failed to initialize arguments.callee on the slow path as well as the fast path
1726         https://bugs.webkit.org/show_bug.cgi?id=144293
1727
1728         Reviewed by Mark Lam.
1729         
1730         The slow path doesn't fully initialize DirectArguments - it leaves callee blank. So, we need
1731         to initialize the callee on the common path after the fast and slow path.
1732
1733         * ftl/FTLLowerDFGToLLVM.cpp:
1734         (JSC::FTL::LowerDFGToLLVM::compileCreateDirectArguments):
1735         * tests/stress/arguments-callee-uninitialized.js: Added.
1736         (foo):
1737
1738 2015-04-27  Benjamin Poulain  <bpoulain@apple.com>
1739
1740         [JSC] Add support for typed arrays to the Array profiling
1741         https://bugs.webkit.org/show_bug.cgi?id=143913
1742
1743         Reviewed by Filip Pizlo.
1744
1745         This patch adds ArrayModes for every typed arrays. Having that information
1746         let us generate better GetByVal and PutByVal when the type speculation
1747         are not good enough.
1748
1749         A typical case where this is useful is any basic block for which the type
1750         of the object is always more restrictive than the speculation (for example, 
1751         a basic block gated by a branch only taken for on type).
1752
1753         * bytecode/ArrayProfile.cpp:
1754         (JSC::dumpArrayModes):
1755         * bytecode/ArrayProfile.h:
1756         (JSC::arrayModeFromStructure):
1757         * dfg/DFGArrayMode.cpp:
1758         (JSC::DFG::ArrayMode::fromObserved):
1759         (JSC::DFG::ArrayMode::refine):
1760         Maintain the refine() semantic. We do not support OutOfBounds access
1761         for GetByVal on typed array.
1762
1763         * runtime/IndexingType.h:
1764         * tests/stress/typed-array-get-by-val-profiling.js: Added.
1765         (testArray.testCode):
1766         (testArray):
1767         * tests/stress/typed-array-put-by-val-profiling.js: Added.
1768         (testArray.testCode):
1769         (testArray):
1770
1771 2015-04-27  Filip Pizlo  <fpizlo@apple.com>
1772
1773         Unreviewed, roll out r183438 "RegExp matches arrays should use contiguous indexing". It
1774         causes many debug test failures.
1775
1776         * runtime/JSGlobalObject.cpp:
1777         (JSC::JSGlobalObject::init):
1778         (JSC::JSGlobalObject::visitChildren):
1779         * runtime/JSGlobalObject.h:
1780         (JSC::JSGlobalObject::regExpMatchesArrayStructure):
1781         * runtime/JSObject.h:
1782         (JSC::JSObject::initializeIndex):
1783         * runtime/RegExpMatchesArray.cpp:
1784         (JSC::createRegExpMatchesArray):
1785
1786 2015-04-27  Andreas Kling  <akling@apple.com>
1787
1788         RegExp matches arrays should use contiguous indexing.
1789         <https://webkit.org/b/144286>
1790
1791         Reviewed by Geoffrey Garen.
1792
1793         We had a custom Structure being used for RegExp matches arrays that would
1794         put the arrays into SlowPutArrayStorageShape mode. This was just left
1795         from when matches arrays were custom, lazily initialized objects.
1796
1797         This change removes that Structure and switches the matches arrays to
1798         using the default ContiguousShape Structure. This allows the FTL JIT
1799         to compile the inner loop of the Octane/regexp benchmark.
1800
1801         Also made a version of initializeIndex() [inline] that takes the indexing
1802         type in an argument, allowing createRegExpMatchesArray() to initialize
1803         the entire array without branching on the indexing type for each entry.
1804
1805         ~3% progression on Octane/regexp.
1806
1807         * runtime/JSGlobalObject.cpp:
1808         (JSC::JSGlobalObject::init):
1809         (JSC::JSGlobalObject::visitChildren):
1810         * runtime/JSGlobalObject.h:
1811         (JSC::JSGlobalObject::mapStructure):
1812         (JSC::JSGlobalObject::regExpMatchesArrayStructure): Deleted.
1813         * runtime/JSObject.h:
1814         (JSC::JSObject::initializeIndex):
1815         * runtime/RegExpMatchesArray.cpp:
1816         (JSC::createRegExpMatchesArray):
1817
1818 2015-04-27  Ryosuke Niwa  <rniwa@webkit.org>
1819
1820         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
1821         https://bugs.webkit.org/show_bug.cgi?id=144257
1822
1823         Temporarily disable skip these tests.
1824
1825         * tests/stress/template-literal-line-terminators.js:
1826         * tests/stress/template-literal-syntax.js:
1827         * tests/stress/template-literal.js:
1828
1829 2015-04-27  Basile Clement  <basile_clement@apple.com>
1830
1831         Function allocations shouldn't sink through Put operations
1832         https://bugs.webkit.org/show_bug.cgi?id=144176
1833
1834         Reviewed by Filip Pizlo.
1835
1836         By design, we don't support function allocation sinking through any
1837         related operation ; however object allocation can sink through PutByOffset et
1838         al.
1839
1840         Currently, the checks to prevent function allocation to sink through
1841         these are misguided and do not prevent anything ; function allocation sinking
1842         through these operations is prevented as a side effect of requiring an
1843         AllocatePropertyStorage through which the function allocation is seen as
1844         escaping.
1845
1846         This changes it so that ObjectAllocationSinkingPhase::handleNode()
1847         checks properly that only object allocations sink through related write
1848         operations.
1849
1850         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1851         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
1852         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1853
1854 2015-04-25  Filip Pizlo  <fpizlo@apple.com>
1855
1856         VarargsForwardingPhase should use bytecode liveness in addition to other uses to determine the last point that a candidate is used
1857         https://bugs.webkit.org/show_bug.cgi?id=143843
1858
1859         Reviewed by Geoffrey Garen.
1860         
1861         It will soon come to pass that Phantom isn't available at the time that
1862         VarargsForwardingPhase runs. So, it needs to use some other mechanism for discovering when
1863         a value dies for OSR.
1864         
1865         This is simplified by two things:
1866         
1867         1) The bytecode kill analysis is now reusable. This patch makes it even more reusable than
1868            before by polishing the API.
1869         
1870         2) This phase already operates on one node at a time and allows itself to do a full search
1871            of the enclosing basic block for that node. This is fine because CreateDirectArguments
1872            and friends is a rarely occurring node. The fact that it operates on one node at a time
1873            makes it even easier to reason about OSR liveness - we just track the list of locals in
1874            which it is live.
1875         
1876         This change has no effect right now but it is a necessary prerequisite to implementing
1877         https://bugs.webkit.org/show_bug.cgi?id=143736.
1878
1879         * dfg/DFGBasicBlock.h:
1880         (JSC::DFG::BasicBlock::tryAt):
1881         * dfg/DFGForAllKills.h:
1882         (JSC::DFG::forAllKilledOperands):
1883         * dfg/DFGPhantomInsertionPhase.cpp:
1884         * dfg/DFGVarargsForwardingPhase.cpp:
1885
1886 2015-04-27  Jordan Harband  <ljharb@gmail.com>
1887
1888         Map#entries and Map#keys error for non-Maps is swapped
1889         https://bugs.webkit.org/show_bug.cgi?id=144253
1890
1891         Reviewed by Simon Fraser.
1892
1893         Correcting error messages on Set/Map methods when called on
1894         incompatible objects.
1895
1896         * runtime/MapPrototype.cpp:
1897         (JSC::mapProtoFuncEntries):
1898         (JSC::mapProtoFuncKeys):
1899         * runtime/SetPrototype.cpp:
1900         (JSC::setProtoFuncEntries):
1901
1902 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
1903
1904         Rationalize DFG DCE handling of nodes that perform checks that propagate through AI
1905         https://bugs.webkit.org/show_bug.cgi?id=144186
1906
1907         Reviewed by Geoffrey Garen.
1908         
1909         If I do ArithAdd(Int32Use, Int32Use, CheckOverflow) then AI will prove that this returns
1910         Int32. We may later perform code simplifications based on the proof that this is Int32, and
1911         we may kill all DFG users of this ArithAdd. Then we may prove that there is no exit site at
1912         which the ArithAdd is live. This seems like it is sufficient to then kill the ArithAdd,
1913         except that we still need the overflow check!
1914
1915         Previously we mishandled this:
1916
1917         - In places where we want the overflow check we need to use MustGenerate(@ArithAdd) as a hack
1918           to keep it alive. That's dirty and it's just indicative of a deeper issue.
1919
1920         - Our MovHint removal doesn't do Phantom canonicalization which essentially makes it
1921           powerless. This was sort of hiding the bug.
1922
1923         - Nodes that have checks that AI leverages should always be NodeMustGenerate. You can't kill
1924           something that you are relying on for subsequent simplifications.
1925         
1926         This fixes MovHint removal to also canonicalize Phantoms. This also adds ModeMustGenerate to
1927         nodes that may perform checks that are used by AI to guarantee the result type. As a result,
1928         we no longer need the weird MustGenerate node.
1929
1930         * dfg/DFGAbstractInterpreterInlines.h:
1931         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1932         * dfg/DFGArgumentsEliminationPhase.cpp:
1933         * dfg/DFGClobberize.h:
1934         (JSC::DFG::clobberize):
1935         * dfg/DFGDCEPhase.cpp:
1936         (JSC::DFG::DCEPhase::run):
1937         * dfg/DFGDoesGC.cpp:
1938         (JSC::DFG::doesGC):
1939         * dfg/DFGFixupPhase.cpp:
1940         (JSC::DFG::FixupPhase::fixupNode):
1941         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
1942         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1943         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1944         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd): Deleted.
1945         * dfg/DFGMayExit.cpp:
1946         (JSC::DFG::mayExit):
1947         * dfg/DFGNode.h:
1948         (JSC::DFG::Node::willHaveCodeGenOrOSR):
1949         * dfg/DFGNodeType.h:
1950         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1951         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1952         * dfg/DFGPhantomCanonicalizationPhase.cpp:
1953         (JSC::DFG::PhantomCanonicalizationPhase::run):
1954         * dfg/DFGPhantomRemovalPhase.cpp:
1955         (JSC::DFG::PhantomRemovalPhase::run):
1956         * dfg/DFGPlan.cpp:
1957         (JSC::DFG::Plan::compileInThreadImpl):
1958         * dfg/DFGPredictionPropagationPhase.cpp:
1959         (JSC::DFG::PredictionPropagationPhase::propagate):
1960         * dfg/DFGSafeToExecute.h:
1961         (JSC::DFG::safeToExecute):
1962         * dfg/DFGSpeculativeJIT32_64.cpp:
1963         (JSC::DFG::SpeculativeJIT::compile):
1964         * dfg/DFGSpeculativeJIT64.cpp:
1965         (JSC::DFG::SpeculativeJIT::compile):
1966         * dfg/DFGTypeCheckHoistingPhase.cpp:
1967         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1968         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1969         * dfg/DFGVarargsForwardingPhase.cpp:
1970         * ftl/FTLCapabilities.cpp:
1971         (JSC::FTL::canCompile):
1972         * ftl/FTLLowerDFGToLLVM.cpp:
1973         (JSC::FTL::LowerDFGToLLVM::compileNode):
1974         * tests/stress/fold-based-on-int32-proof-mul-branch.js: Added.
1975         (foo):
1976         * tests/stress/fold-based-on-int32-proof-mul.js: Added.
1977         (foo):
1978         * tests/stress/fold-based-on-int32-proof-or-zero.js: Added.
1979         (foo):
1980         * tests/stress/fold-based-on-int32-proof.js: Added.
1981         (foo):
1982
1983 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1984
1985         Class body ending with a semicolon throws a SyntaxError
1986         https://bugs.webkit.org/show_bug.cgi?id=144244
1987
1988         Reviewed by Darin Adler.
1989
1990         The bug was caused by parseClass's inner loop for method definitions not moving onto the next iteration
1991         it encounters a semicolon. As a result, we always expected a method to appear after a semicolon. Fixed
1992         it by continue'ing when it encounters a semicolon.
1993
1994         * parser/Parser.cpp:
1995         (JSC::Parser<LexerType>::parseClass):
1996
1997 2015-04-26  Ryosuke Niwa  <rniwa@webkit.org>
1998
1999         Getter or setter method named "prototype" or "constrcutor" should throw SyntaxError
2000         https://bugs.webkit.org/show_bug.cgi?id=144243
2001
2002         Reviewed by Darin Adler.
2003
2004         Fixed the bug by adding explicit checks in parseGetterSetter when we're parsing class methods.
2005
2006         * parser/Parser.cpp:
2007         (JSC::Parser<LexerType>::parseGetterSetter):
2008
2009 2015-04-26  Jordan Harband  <ljharb@gmail.com>
2010
2011         Map#forEach does not pass "map" argument to callback.
2012         https://bugs.webkit.org/show_bug.cgi?id=144187
2013
2014         Reviewed by Darin Adler.
2015
2016         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-map.prototype.foreach
2017         step 7.a.i., the callback should be called with three arguments.
2018
2019         * runtime/MapPrototype.cpp:
2020         (JSC::mapProtoFuncForEach):
2021
2022 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
2023
2024         [ES6] Implement ES6 template literals
2025         https://bugs.webkit.org/show_bug.cgi?id=142691
2026
2027         Reviewed by Darin Adler.
2028
2029         This patch implements TemplateLiteral.
2030         Since TaggedTemplate requires some global states and
2031         primitive operations like GetTemplateObject,
2032         we separate the patch. It will be implemented in a subsequent patch.
2033
2034         Template Literal Syntax is guarded by ENABLE_ES6_TEMPLATE_LITERAL_SYNTAX compile time flag.
2035         By disabling it, we can disable Template Literal support.
2036
2037         To implement template literals, in this patch,
2038         we newly introduces bytecode op_to_string.
2039         In template literals, we alternately evaluate the expression and
2040         perform ToString onto the result of evaluation.
2041         For example,
2042
2043         `${f1()} ${f2()}`
2044
2045         In this template literal, execution order is the following,
2046         1. calling f1()
2047         2. ToString(the result of f1())
2048         3. calling f2()
2049         4. ToString(the result of f2())
2050
2051         op_strcat also performs ToString. However, performing ToString
2052         onto expressions are batched in op_strcat, it's not the same to the
2053         template literal spec. In the above example,
2054         ToString(f1()) should be called before calling f2().
2055
2056         * Configurations/FeatureDefines.xcconfig:
2057         * bytecode/BytecodeList.json:
2058         * bytecode/BytecodeUseDef.h:
2059         (JSC::computeUsesForBytecodeOffset):
2060         (JSC::computeDefsForBytecodeOffset):
2061         * bytecode/CodeBlock.cpp:
2062         (JSC::CodeBlock::dumpBytecode):
2063         * bytecompiler/BytecodeGenerator.h:
2064         (JSC::BytecodeGenerator::emitToString):
2065         (JSC::BytecodeGenerator::emitToNumber): Deleted.
2066         * bytecompiler/NodesCodegen.cpp:
2067         (JSC::TemplateStringNode::emitBytecode):
2068         (JSC::TemplateLiteralNode::emitBytecode):
2069         * dfg/DFGByteCodeParser.cpp:
2070         (JSC::DFG::ByteCodeParser::parseBlock):
2071         * dfg/DFGCapabilities.cpp:
2072         (JSC::DFG::capabilityLevel):
2073         * jit/JIT.cpp:
2074         (JSC::JIT::privateCompileMainPass):
2075         (JSC::JIT::privateCompileSlowCases):
2076         * jit/JIT.h:
2077         * jit/JITOpcodes.cpp:
2078         (JSC::JIT::emit_op_to_string):
2079         (JSC::JIT::emitSlow_op_to_string):
2080         * jit/JITOpcodes32_64.cpp:
2081         (JSC::JIT::emit_op_to_string):
2082         (JSC::JIT::emitSlow_op_to_string):
2083         * llint/LowLevelInterpreter32_64.asm:
2084         * llint/LowLevelInterpreter64.asm:
2085         * parser/ASTBuilder.h:
2086         (JSC::ASTBuilder::createTemplateString):
2087         (JSC::ASTBuilder::createTemplateStringList):
2088         (JSC::ASTBuilder::createTemplateExpressionList):
2089         (JSC::ASTBuilder::createTemplateLiteral):
2090         * parser/Lexer.cpp:
2091         (JSC::Lexer<T>::Lexer):
2092         (JSC::Lexer<T>::parseIdentifierSlowCase):
2093         (JSC::Lexer<T>::parseString):
2094         (JSC::LineNumberAdder::LineNumberAdder):
2095         (JSC::LineNumberAdder::clear):
2096         (JSC::LineNumberAdder::add):
2097         (JSC::Lexer<T>::parseTemplateLiteral):
2098         (JSC::Lexer<T>::lex):
2099         (JSC::Lexer<T>::scanRegExp):
2100         (JSC::Lexer<T>::scanTrailingTemplateString):
2101         (JSC::Lexer<T>::parseStringSlowCase): Deleted.
2102         * parser/Lexer.h:
2103         * parser/NodeConstructors.h:
2104         (JSC::TemplateExpressionListNode::TemplateExpressionListNode):
2105         (JSC::TemplateStringNode::TemplateStringNode):
2106         (JSC::TemplateStringListNode::TemplateStringListNode):
2107         (JSC::TemplateLiteralNode::TemplateLiteralNode):
2108         * parser/Nodes.h:
2109         (JSC::TemplateExpressionListNode::value):
2110         (JSC::TemplateExpressionListNode::next):
2111         (JSC::TemplateStringNode::cooked):
2112         (JSC::TemplateStringNode::raw):
2113         (JSC::TemplateStringListNode::value):
2114         (JSC::TemplateStringListNode::next):
2115         * parser/Parser.cpp:
2116         (JSC::Parser<LexerType>::parseTemplateString):
2117         (JSC::Parser<LexerType>::parseTemplateLiteral):
2118         (JSC::Parser<LexerType>::parsePrimaryExpression):
2119         * parser/Parser.h:
2120         * parser/ParserTokens.h:
2121         * parser/SyntaxChecker.h:
2122         (JSC::SyntaxChecker::createTemplateString):
2123         (JSC::SyntaxChecker::createTemplateStringList):
2124         (JSC::SyntaxChecker::createTemplateExpressionList):
2125         (JSC::SyntaxChecker::createTemplateLiteral):
2126         (JSC::SyntaxChecker::createSpreadExpression): Deleted.
2127         * runtime/CommonSlowPaths.cpp:
2128         (JSC::SLOW_PATH_DECL):
2129         * runtime/CommonSlowPaths.h:
2130         * tests/stress/template-literal-line-terminators.js: Added.
2131         (test):
2132         (testEval):
2133         (testEvalLineNumber):
2134         * tests/stress/template-literal-syntax.js: Added.
2135         (testSyntax):
2136         (testSyntaxError):
2137         * tests/stress/template-literal.js: Added.
2138         (test):
2139         (testEval):
2140         (testEmbedded):
2141
2142 2015-04-26  Jordan Harband  <ljharb@gmail.com>
2143
2144         Set#forEach does not pass "key" or "set" arguments to callback.
2145         https://bugs.webkit.org/show_bug.cgi?id=144188
2146
2147         Reviewed by Darin Adler.
2148
2149         Per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.foreach
2150         Set#forEach should pass 3 arguments to the callback.
2151
2152         * runtime/SetPrototype.cpp:
2153         (JSC::setProtoFuncForEach):
2154
2155 2015-04-26  Benjamin Poulain  <benjamin@webkit.org>
2156
2157         [JSC] Implement Math.clz32(), remove Number.clz()
2158         https://bugs.webkit.org/show_bug.cgi?id=144205
2159
2160         Reviewed by Michael Saboff.
2161
2162         This patch adds the ES6 function Math.clz32(), and remove the non-standard
2163         Number.clz(). Number.clz() probably came from an older draft.
2164
2165         The new function has a corresponding instrinsic: Clz32Intrinsic,
2166         and a corresponding DFG node: ArithClz32, optimized all the way to LLVM.
2167
2168         * assembler/MacroAssemblerX86Common.h:
2169         (JSC::MacroAssemblerX86Common::countLeadingZeros32):
2170         * assembler/X86Assembler.h:
2171         (JSC::X86Assembler::bsr_rr):
2172         The x86 assembler did not have countLeadingZeros32() because there is
2173         no native CLZ instruction on that architecture.
2174
2175         I have added the version with bsr + branches for the case of zero.
2176         An other popular version uses cmov to handle the case of zero. I kept
2177         it simple since the Assembler has no support for cmov.
2178
2179         It is unlikely to matter much. If the code is hot enough, LLVM picks
2180         something good based on the surrounding code.
2181
2182         * dfg/DFGAbstractInterpreterInlines.h:
2183         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2184         Constant handling + effect propagation. The node only produces integer (between 0 and 32).
2185
2186         * dfg/DFGBackwardsPropagationPhase.cpp:
2187         (JSC::DFG::BackwardsPropagationPhase::propagate):
2188         Thanks to the definition of toUint32(), we can ignore plenty of details
2189         from doubles.
2190
2191         * dfg/DFGByteCodeParser.cpp:
2192         (JSC::DFG::ByteCodeParser::handleIntrinsic):
2193         * dfg/DFGClobberize.h:
2194         (JSC::DFG::clobberize):
2195         * dfg/DFGDoesGC.cpp:
2196         (JSC::DFG::doesGC):
2197         * dfg/DFGFixupPhase.cpp:
2198         (JSC::DFG::FixupPhase::fixupNode):
2199         * dfg/DFGNodeType.h:
2200         * dfg/DFGPredictionPropagationPhase.cpp:
2201         (JSC::DFG::PredictionPropagationPhase::propagate):
2202         * dfg/DFGSafeToExecute.h:
2203         (JSC::DFG::safeToExecute):
2204         * dfg/DFGSpeculativeJIT.cpp:
2205         (JSC::DFG::SpeculativeJIT::compileArithClz32):
2206         * dfg/DFGSpeculativeJIT.h:
2207         * dfg/DFGSpeculativeJIT32_64.cpp:
2208         (JSC::DFG::SpeculativeJIT::compile):
2209         * dfg/DFGSpeculativeJIT64.cpp:
2210         (JSC::DFG::SpeculativeJIT::compile):
2211         * ftl/FTLCapabilities.cpp:
2212         (JSC::FTL::canCompile):
2213         * ftl/FTLIntrinsicRepository.h:
2214         * ftl/FTLLowerDFGToLLVM.cpp:
2215         (JSC::FTL::LowerDFGToLLVM::compileNode):
2216         (JSC::FTL::LowerDFGToLLVM::compileArithClz32):
2217         * ftl/FTLOutput.h:
2218         (JSC::FTL::Output::ctlz32):
2219         * jit/ThunkGenerators.cpp:
2220         (JSC::clz32ThunkGenerator):
2221         * jit/ThunkGenerators.h:
2222         * runtime/Intrinsic.h:
2223         * runtime/MathCommon.h:
2224         (JSC::clz32):
2225         Fun fact: InstCombine does not recognize this pattern to eliminate
2226         the branch which makes our FTL version better than the C version.
2227
2228         * runtime/MathObject.cpp:
2229         (JSC::MathObject::finishCreation):
2230         (JSC::mathProtoFuncClz32):
2231         * runtime/NumberPrototype.cpp:
2232         (JSC::clz): Deleted.
2233         (JSC::numberProtoFuncClz): Deleted.
2234         * runtime/VM.cpp:
2235         (JSC::thunkGeneratorForIntrinsic):
2236         * tests/stress/math-clz32-basics.js: Added.
2237         (mathClz32OnInteger):
2238         (testMathClz32OnIntegers):
2239         (verifyMathClz32OnIntegerWithOtherTypes):
2240         (mathClz32OnDouble):
2241         (testMathClz32OnDoubles):
2242         (verifyMathClz32OnDoublesWithOtherTypes):
2243         (mathClz32NoArguments):
2244         (mathClz32TooManyArguments):
2245         (testMathClz32OnConstants):
2246         (mathClz32StructTransition):
2247         (Math.clz32):
2248
2249 2015-04-26  Yusuke Suzuki  <utatane.tea@gmail.com>
2250
2251         [ES6] Array.from need to accept iterables
2252         https://bugs.webkit.org/show_bug.cgi?id=141055
2253
2254         Reviewed by Darin Adler.
2255
2256         ES6 spec requires that Array.from accepts iterable objects.
2257         This patch introduces this functionality, Array.from accepting iterable objects.
2258
2259         Currently, `isConstructor` is not used. Instead of it, `typeof thiObj === "function"` is used.
2260         However, it doesn't conform to the spec. While `isConstructor` queries the given object has `[[Construct]]`,
2261         `typeof thisObj === "function"` queries the given object has `[[Call]]`.
2262         This will be fixed in the subsequent patch[1].
2263
2264         [1]: https://bugs.webkit.org/show_bug.cgi?id=144093
2265
2266         * builtins/ArrayConstructor.js:
2267         (from):
2268         * parser/Parser.cpp:
2269         (JSC::Parser<LexerType>::parseInner):
2270         * runtime/CommonIdentifiers.h:
2271         * runtime/JSGlobalObject.cpp:
2272         (JSC::JSGlobalObject::init):
2273         * tests/stress/array-from-with-iterable.js: Added.
2274         (shouldBe):
2275         (.set for):
2276         (.set var):
2277         (.get var):
2278         (argumentsGenerators):
2279         (.set shouldBe):
2280         (.set new):
2281         * tests/stress/array-from-with-iterator.js: Added.
2282         (shouldBe):
2283         (shouldThrow):
2284         (createIterator.iterator.return):
2285         (createIterator):
2286         (.):
2287
2288 2015-04-25  Jordan Harband  <ljharb@gmail.com>
2289
2290         Set#keys !== Set#values
2291         https://bugs.webkit.org/show_bug.cgi?id=144190
2292
2293         Reviewed by Darin Adler.
2294
2295         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype.keys
2296         Set#keys should === Set#values
2297
2298         * runtime/SetPrototype.cpp:
2299         (JSC::SetPrototype::finishCreation):
2300         (JSC::setProtoFuncValues):
2301         (JSC::setProtoFuncEntries):
2302         (JSC::setProtoFuncKeys): Deleted.
2303
2304 2015-04-25  Joseph Pecoraro  <pecoraro@apple.com>
2305
2306         Allow for pausing a JSContext when opening a Web Inspector
2307         <rdar://problem/20564788>
2308
2309         Reviewed by Timothy Hatcher.
2310
2311         * inspector/remote/RemoteInspector.mm:
2312         (Inspector::RemoteInspector::receivedSetupMessage):
2313         * inspector/remote/RemoteInspectorConstants.h:
2314         * inspector/remote/RemoteInspectorDebuggable.h:
2315         * inspector/remote/RemoteInspectorDebuggableConnection.h:
2316         * inspector/remote/RemoteInspectorDebuggableConnection.mm:
2317         (Inspector::RemoteInspectorDebuggableConnection::setup):
2318         On any incoming setup message, we may want to automatically
2319         pause the debuggable. If requested, pause the debuggable
2320         after we have setup the frontend connection.
2321
2322         * runtime/JSGlobalObjectDebuggable.h:
2323         * runtime/JSGlobalObjectDebuggable.cpp:
2324         (JSC::JSGlobalObjectDebuggable::pause):
2325         Pass through to the inspector controller.
2326
2327         * inspector/JSGlobalObjectInspectorController.h:
2328         * inspector/JSGlobalObjectInspectorController.cpp:
2329         (Inspector::JSGlobalObjectInspectorController::pause):
2330         Enable pause on next statement.
2331
2332 2015-04-23  Ryosuke Niwa  <rniwa@webkit.org>
2333
2334         class methods should be non-enumerable
2335         https://bugs.webkit.org/show_bug.cgi?id=143181
2336
2337         Reviewed by Darin Adler.
2338
2339         Fixed the bug by using Object.defineProperty to define methods.
2340
2341         This patch adds the concept of link time constants and uses it to resolve Object.defineProperty
2342         inside CodeBlock's constructor since bytecode can be linked against multiple global objects.
2343
2344         * bytecode/CodeBlock.cpp: 
2345         (JSC::CodeBlock::CodeBlock): Resolve link time constants that are used. Ignore ones with register
2346         index of zero.
2347         * bytecode/SpecialPointer.h: Added a new enum for link time constants. It currently contains
2348         exactly one entry for Object.defineProperty.
2349         * bytecode/UnlinkedCodeBlock.h:
2350         (JSC::UnlinkedCodeBlock::addConstant): Added. Like addConstant that takes JSValue, allocate a new
2351         constant register for the link time constant we're adding.
2352         (JSC::UnlinkedCodeBlock::registerIndexForLinkTimeConstant): Added.
2353         * bytecompiler/BytecodeGenerator.cpp:
2354         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant): Added. Like addConstantValue, allocate a new
2355         register for the specified link time constant and notify UnlinkedCodeBlock about it.
2356         (JSC::BytecodeGenerator::emitCallDefineProperty): Added. Create a new property descriptor and call
2357         Object.defineProperty with it.
2358         * bytecompiler/BytecodeGenerator.h:
2359         * bytecompiler/NodesCodegen.cpp:
2360         (JSC::PropertyListNode::emitBytecode): Make static and non-static getters and setters for classes
2361         non-enumerable by using emitCallDefineProperty to define them.
2362         (JSC::PropertyListNode::emitPutConstantProperty): Ditto for a non-accessor properties.
2363         (JSC::ClassExprNode::emitBytecode): Make prototype.constructor non-enumerable and make prototype
2364         property on the class non-writable, non-configurable, and non-enumerable by using defineProperty.
2365         * runtime/CommonIdentifiers.h:
2366         * runtime/JSGlobalObject.cpp:
2367         (JSC::JSGlobalObject::init): Set m_definePropertyFunction.
2368         (JSC::JSGlobalObject::visitChildren): Visit m_definePropertyFunction.
2369         * runtime/JSGlobalObject.h:
2370         (JSC::JSGlobalObject::definePropertyFunction): Added.
2371         (JSC::JSGlobalObject::actualPointerFor): Added a variant that takes LinkTimeConstant.
2372         (JSC::JSGlobalObject::jsCellForLinkTimeConstant): Like actualPointerFor, takes LinkTimeConstant and
2373         returns a JSCell; e.g. Object.defineProperty.
2374         * runtime/ObjectConstructor.cpp:
2375         (JSC::ObjectConstructor::addDefineProperty): Added. Returns Object.defineProperty.
2376         * runtime/ObjectConstructor.h:
2377
2378 2015-04-25  Yusuke Suzuki  <utatane.tea@gmail.com>
2379
2380         [ES6] Implement String.fromCodePoint
2381         https://bugs.webkit.org/show_bug.cgi?id=144160
2382
2383         Reviewed by Darin Adler.
2384
2385         This patch implements String.fromCodePoint.
2386         It accepts multiple code points and generates a string that consists of given code points.
2387         The range [0x0000 - 0x10FFFF] is valid for code points.
2388         If the given value is out of range, throw a range error.
2389
2390         When a 0xFFFF <= valid code point is given,
2391         String.fromCodePoint generates a string that contains surrogate pairs.
2392
2393         * runtime/StringConstructor.cpp:
2394         (JSC::stringFromCodePoint):
2395         (JSC::constructWithStringConstructor):
2396         * tests/stress/string-from-code-point.js: Added.
2397         (shouldBe):
2398         (shouldThrow):
2399         (toCodePoints):
2400         (passThrough):
2401
2402 2015-04-25  Martin Robinson  <mrobinson@igalia.com>
2403
2404         Rename ENABLE_3D_RENDERING to ENABLE_3D_TRANSFORMS
2405         https://bugs.webkit.org/show_bug.cgi?id=144182
2406
2407         Reviewed by Simon Fraser.
2408
2409         * Configurations/FeatureDefines.xcconfig: Replace all instances of 3D_RENDERING with 3D_TRANSFORMS.
2410
2411 2015-04-25  Mark Lam  <mark.lam@apple.com>
2412
2413         mayExit() is wrong about Branch nodes with ObjectOrOtherUse: they can exit.
2414         https://bugs.webkit.org/show_bug.cgi?id=144152
2415
2416         Reviewed by Filip Pizlo.
2417
2418         Changed the EdgeMayExit functor to recognize ObjectUse, ObjectOrOtherUse,
2419         StringObjectUse, and StringOrStringObjectUse kinds as potentially triggering
2420         OSR exits.  This was overlooked in the original code.
2421
2422         While only the ObjectOrOtherUse kind is relevant for manifesting this bug with
2423         the Branch node, the other 3 may also trigger the same bug for other nodes.
2424         To prevent this bug from manifesting with other nodes (and future ones that
2425         are yet to be added to mayExits()'s "potential won't exit" set), we fix the
2426         EdgeMayExit functor to handle all 4 use kinds (instead of just ObjectOrOtherUse).
2427
2428         Also added a test to exercise a code path that will trigger this bug with
2429         the Branch node before the fix is applied.
2430
2431         * dfg/DFGMayExit.cpp:
2432         * tests/stress/branch-may-exit-due-to-object-or-other-use-kind.js: Added.
2433         (inlinedFunction):
2434         (foo):
2435
2436 2015-04-24  Commit Queue  <commit-queue@webkit.org>
2437
2438         Unreviewed, rolling out r183288.
2439         https://bugs.webkit.org/show_bug.cgi?id=144189
2440
2441         Made js/sort-with-side-effecting-comparisons.html time out in
2442         debug builds (Requested by ap on #webkit).
2443
2444         Reverted changeset:
2445
2446         "It shouldn't take 1846 lines of code and 5 FIXMEs to sort an
2447         array."
2448         https://bugs.webkit.org/show_bug.cgi?id=144013
2449         http://trac.webkit.org/changeset/183288
2450
2451 2015-04-24  Filip Pizlo  <fpizlo@apple.com>
2452
2453         CRASH in operationCreateDirectArgumentsDuringExit()
2454         https://bugs.webkit.org/show_bug.cgi?id=143962
2455
2456         Reviewed by Geoffrey Garen.
2457         
2458         We shouldn't assume that constant-like OSR exit values are always recoverable. They are only
2459         recoverable so long as they are live. Therefore, OSR exit should track liveness of
2460         constants instead of assuming that they are always live.
2461
2462         * dfg/DFGGenerationInfo.h:
2463         (JSC::DFG::GenerationInfo::noticeOSRBirth):
2464         (JSC::DFG::GenerationInfo::appendBirth):
2465         * dfg/DFGSpeculativeJIT.cpp:
2466         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2467         * dfg/DFGVariableEvent.cpp:
2468         (JSC::DFG::VariableEvent::dump):
2469         * dfg/DFGVariableEvent.h:
2470         (JSC::DFG::VariableEvent::birth):
2471         (JSC::DFG::VariableEvent::id):
2472         (JSC::DFG::VariableEvent::dataFormat):
2473         * dfg/DFGVariableEventStream.cpp:
2474         (JSC::DFG::VariableEventStream::reconstruct):
2475         * tests/stress/phantom-direct-arguments-clobber-argument-count.js: Added.
2476         (foo):
2477         (bar):
2478         * tests/stress/phantom-direct-arguments-clobber-callee.js: Added.
2479         (foo):
2480         (bar):
2481
2482 2015-04-24  Benjamin Poulain  <bpoulain@apple.com>
2483
2484         [JSC] When inserting a NaN into a Int32 array, we convert it to DoubleArray then to ContiguousArray
2485         https://bugs.webkit.org/show_bug.cgi?id=144169
2486
2487         Reviewed by Geoffrey Garen.
2488
2489         * runtime/JSObject.cpp:
2490         (JSC::JSObject::convertInt32ForValue):
2491         DoubleArray do not store NaN, they are used for holes.
2492         What happened was:
2493         1) We fail to insert the NaN in the Int32 array because it is a double.
2494         2) We were converting the array to DoubleArray.
2495         3) We were trying to insert the value again. We would fail again because
2496            DoubleArray does not store NaN.
2497         4) We would convert the DoubleArrayt to Contiguous Array, converting the values
2498            to boxed values.
2499
2500         * tests/stress/int32array-transition-on-nan.js: Added.
2501         The behavior is not really observable. This only test nothing crashes in those
2502         cases.
2503
2504         (insertNaNWhileFilling):
2505         (testInsertNaNWhileFilling):
2506         (insertNaNAfterFilling):
2507         (testInsertNaNAfterFilling):
2508         (pushNaNWhileFilling):
2509         (testPushNaNWhileFilling):
2510
2511 2015-04-21  Geoffrey Garen  <ggaren@apple.com>
2512
2513         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
2514         https://bugs.webkit.org/show_bug.cgi?id=144013
2515
2516         Reviewed by Mark Lam.
2517
2518         This patch implements Array.prototype.sort in JavaScript, removing the
2519         C++ implementations. It is simpler and less error-prone to express our
2520         operations in JavaScript, which provides memory safety, exception safety,
2521         and recursion safety.
2522
2523         The performance result is mixed, but net positive in my opinion. It's
2524         difficult to enumerate all the results, since we used to have so many
2525         different sorting modes, and there are lots of different data patterns
2526         across which you might want to measure sorting. Suffice it to say:
2527
2528             (*) The benchmarks we track are faster or unchanged.
2529
2530             (*) Sorting random input using a comparator -- which we think is
2531             common -- is 3X faster.
2532
2533             (*) Sorting random input in a non-array object -- which jQuery does
2534             -- is 4X faster.
2535
2536             (*) Sorting random input in a compact array of integers using a
2537             trivial pattern-matchable comparator is 2X *slower*.
2538
2539         * builtins/Array.prototype.js:
2540         (sort.min):
2541         (sort.stringComparator):
2542         (sort.compactSparse): Special case compaction for sparse arrays because
2543         we don't want to hang when sorting new Array(BIG).
2544
2545         (sort.compact):
2546         (sort.merge):
2547         (sort.mergeSort): Use merge sort because it's a reasonably efficient
2548         stable sort. We have evidence that some sites depend on stable sort,
2549         even though the ES6 spec does not mandate it. (See
2550         <http://trac.webkit.org/changeset/33967>.)
2551
2552         This is a textbook implementation of merge sort with three optimizations:
2553
2554             (1) Use iteration instead of recursion;
2555
2556             (2) Use array subscripting instead of array copying in order to
2557             create logical sub-lists without creating physical sub-lists;
2558
2559             (3) Swap src and dst at each iteration instead of copying src into
2560             dst, and only copy src into the subject array at the end if src is
2561             not the subject array.
2562
2563         (sort.inflate):
2564         (sort.comparatorSort):
2565         (sort): Sort in JavaScript for the win.
2566
2567         * builtins/BuiltinExecutables.cpp:
2568         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
2569         names so we can use helper functions.
2570
2571         * bytecode/CodeBlock.h:
2572         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
2573         * bytecode/UnlinkedCodeBlock.cpp:
2574         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2575         * bytecode/UnlinkedCodeBlock.h:
2576         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
2577         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
2578         * bytecompiler/BytecodeGenerator.cpp:
2579         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
2580         * bytecompiler/BytecodeGenerator.h:
2581         * bytecompiler/NodesCodegen.cpp:
2582         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
2583         on pattern matching anymore. This was mainly an optimization to avoid 
2584         the overhead of calling from C++ to JS, which we now avoid by
2585         sorting in JS.
2586
2587         * heap/Heap.cpp:
2588         (JSC::Heap::markRoots):
2589         (JSC::Heap::pushTempSortVector): Deleted.
2590         (JSC::Heap::popTempSortVector): Deleted.
2591         (JSC::Heap::visitTempSortVectors): Deleted.
2592         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
2593         in JavaScript using a normal JavaScript array for our temporary storage.
2594
2595         * parser/Parser.cpp:
2596         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
2597         helper functions.
2598
2599         * runtime/ArrayPrototype.cpp:
2600         (JSC::isNumericCompareFunction): Deleted.
2601         (JSC::attemptFastSort): Deleted.
2602         (JSC::performSlowSort): Deleted.
2603         (JSC::arrayProtoFuncSort): Deleted.
2604
2605         * runtime/CommonIdentifiers.h: New strings used by sort.
2606
2607         * runtime/JSArray.cpp:
2608         (JSC::compareNumbersForQSortWithInt32): Deleted.
2609         (JSC::compareNumbersForQSortWithDouble): Deleted.
2610         (JSC::compareNumbersForQSort): Deleted.
2611         (JSC::compareByStringPairForQSort): Deleted.
2612         (JSC::JSArray::sortNumericVector): Deleted.
2613         (JSC::JSArray::sortNumeric): Deleted.
2614         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
2615         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
2616         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
2617         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
2618         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
2619         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
2620         (JSC::JSArray::sortCompactedVector): Deleted.
2621         (JSC::JSArray::sort): Deleted.
2622         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
2623         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
2624         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
2625         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
2626         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
2627         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
2628         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
2629         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
2630         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
2631         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
2632         (JSC::JSArray::sortVector): Deleted.
2633         (JSC::JSArray::compactForSorting): Deleted.
2634         * runtime/JSArray.h:
2635
2636         * runtime/JSGlobalObject.cpp:
2637         (JSC::JSGlobalObject::init):
2638         * runtime/ObjectConstructor.cpp:
2639         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
2640         by sort.
2641
2642 2015-04-24  Matthew Mirman  <mmirman@apple.com>
2643
2644         Made Object.prototype.__proto__ native getter and setter check that this object not null or undefined
2645         https://bugs.webkit.org/show_bug.cgi?id=141865
2646         rdar://problem/19927273
2647
2648         Reviewed by Filip Pizlo.
2649
2650         * runtime/JSGlobalObjectFunctions.cpp:
2651         (JSC::globalFuncProtoGetter):
2652         (JSC::globalFuncProtoSetter):
2653
2654 2015-04-23  Benjamin Poulain  <bpoulain@apple.com>
2655
2656         Remove a useless branch on DFGGraph::addShouldSpeculateMachineInt()
2657         https://bugs.webkit.org/show_bug.cgi?id=144118
2658
2659         Reviewed by Geoffrey Garen.
2660
2661         * dfg/DFGGraph.h:
2662         (JSC::DFG::Graph::addShouldSpeculateMachineInt):
2663         Both block do the same thing.
2664
2665 2015-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2666
2667         Web Inspector: Speculative fix for non-main thread auto-attach failures
2668         https://bugs.webkit.org/show_bug.cgi?id=144134
2669
2670         Reviewed by Timothy Hatcher.
2671
2672         * inspector/remote/RemoteInspector.mm:
2673         (Inspector::RemoteInspector::singleton):
2674
2675 2015-04-23  Basile Clement  <basile_clement@apple.com>
2676
2677         Allow function allocation sinking
2678         https://bugs.webkit.org/show_bug.cgi?id=144016
2679
2680         Reviewed by Filip Pizlo.
2681
2682         This adds the ability to sink function allocations in the
2683         DFGObjectAllocationSinkingPhase.
2684
2685         In order to enable this, we add a new PhantomNewFunction node that is
2686         used similarily to the PhantomNewObject node, i.e. as a placeholder to replace
2687         a sunk NewFunction and keep track of the allocations that have to be performed
2688         in case of OSR exit after the sunk allocation but before the real one.
2689         The FunctionExecutable and JSLexicalEnvironment (activation) of the function
2690         are stored onto the PhantomNewFunction through PutHints in order for them
2691         to be recovered on OSR exit.
2692
2693         Contrary to sunk object allocations, sunk function allocations do not
2694         support any kind of operations (e.g. storing into a field) ; any such operation
2695         will mark the function allocation as escaping and trigger materialization. As
2696         such, function allocations can only be sunk to places where it would have been
2697         correct to syntactically move them, and we don't need a special
2698         MaterializeNewFunction node to recover possible operations on the function. A
2699         sunk NewFunction node will simply create new NewFunction nodes, then replace
2700         itself with a PhantomNewFunction node.
2701
2702         In itself, this change is not expected to have a significant impact on
2703         performances other than in degenerate cases (see e.g.
2704         JSRegress/sink-function), but it is a step towards being able to sink recursive
2705         closures onces we support CreateActivation sinking as well as allocation cycles
2706         sinking.
2707
2708         * dfg/DFGAbstractInterpreterInlines.h:
2709         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2710         * dfg/DFGClobberize.h:
2711         (JSC::DFG::clobberize):
2712         * dfg/DFGDoesGC.cpp:
2713         (JSC::DFG::doesGC):
2714         * dfg/DFGFixupPhase.cpp:
2715         (JSC::DFG::FixupPhase::fixupNode):
2716         * dfg/DFGNode.h:
2717         (JSC::DFG::Node::convertToPhantomNewFunction):
2718         (JSC::DFG::Node::isPhantomAllocation):
2719         * dfg/DFGNodeType.h:
2720         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2721         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2722         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2723         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2724         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2725         * dfg/DFGPredictionPropagationPhase.cpp:
2726         (JSC::DFG::PredictionPropagationPhase::propagate):
2727         * dfg/DFGPromotedHeapLocation.cpp:
2728         (WTF::printInternal):
2729         * dfg/DFGPromotedHeapLocation.h:
2730         * dfg/DFGSafeToExecute.h:
2731         (JSC::DFG::safeToExecute):
2732         * dfg/DFGSpeculativeJIT32_64.cpp:
2733         (JSC::DFG::SpeculativeJIT::compile):
2734         * dfg/DFGSpeculativeJIT64.cpp:
2735         (JSC::DFG::SpeculativeJIT::compile):
2736         * dfg/DFGValidate.cpp:
2737         (JSC::DFG::Validate::validateCPS):
2738         * ftl/FTLCapabilities.cpp:
2739         (JSC::FTL::canCompile):
2740         * ftl/FTLLowerDFGToLLVM.cpp:
2741         (JSC::FTL::LowerDFGToLLVM::compileNode):
2742         * ftl/FTLOperations.cpp:
2743         (JSC::FTL::operationMaterializeObjectInOSR):
2744         * tests/stress/function-sinking-no-double-allocate.js: Added.
2745         (call):
2746         (.f):
2747         (sink):
2748         * tests/stress/function-sinking-osrexit.js: Added.
2749         (.g):
2750         (sink):
2751         * tests/stress/function-sinking-put.js: Added.
2752         (.g):
2753         (sink):
2754
2755 2015-04-23  Basile Clement  <basile_clement@apple.com>
2756
2757         Make FunctionRareData allocation thread-safe
2758         https://bugs.webkit.org/show_bug.cgi?id=144001
2759
2760         Reviewed by Mark Lam.
2761
2762         The two things we want to prevent are:
2763
2764          1. A thread seeing a pointer to a not-yet-fully-created rare data from
2765             a JSFunction
2766          2. A thread seeing a pointer to a not-yet-fully-created Structure from
2767             an ObjectAllocationProfile
2768
2769         For 1., only the JS thread can be creating the rare data (in
2770         runtime/CommonSlowPaths.cpp or in dfg/DFGOperations.cpp), so we don't need to
2771         worry about concurrent writes, and we don't need any fences when *reading* the
2772         rare data from the JS thread. Thus we only need a storeStoreFence between the
2773         rare data creation and assignment to m_rareData in
2774         JSFunction::createAndInitializeRareData() to ensure that when the store to
2775         m_rareData is issued, the rare data has been properly created.
2776
2777         For the DFG compilation threads, the only place they can access the
2778         rare data is through JSFunction::rareData(), and so we only need a
2779         loadLoadFence there to ensure that when we see a non-null pointer in
2780         m_rareData, the pointed object will be seen as a fully created
2781         FunctionRareData.
2782
2783
2784         For 2., the structure is created in
2785         ObjectAllocationProfile::initialize() (which appears to be called only by the
2786         JS thread as well, in bytecode/CodeBlock.cpp and on rare data initialization,
2787         which always happen in the JS thread), and read through
2788         ObjectAllocationProfile::structure() and
2789         ObjectAllocationProfile::inlineCapacity(), so following the same reasoning we
2790         put a storeStoreFence in ObjectAllocationProfile::initialize() and a
2791         loadLoadFence in ObjectAllocationProfile::structure() (and change
2792         ObjectAllocationProfile::inlineCapacity() to go through
2793         ObjectAllocationProfile::structure()).
2794
2795         We don't need a fence in ObjectAllocationProfile::clear() because
2796         clearing the structure is already as atomic as it gets.
2797
2798         Finally, notice that we don't care about the ObjectAllocationProfile's
2799         m_allocator as that is only used by ObjectAllocationProfile::initialize() and
2800         ObjectAllocationProfile::clear() that are always run in the JS thread.
2801         ObjectAllocationProfile::isNull() could cause some trouble, but it is
2802         currently only used in the ObjectAllocationProfile::clear()'s ASSERT in the JS
2803         thread.  Doing isNull()-style pre-checks would be wrong in any other concurrent
2804         thread anyway.
2805
2806         * bytecode/ObjectAllocationProfile.h:
2807         (JSC::ObjectAllocationProfile::initialize):
2808         (JSC::ObjectAllocationProfile::structure):
2809         (JSC::ObjectAllocationProfile::inlineCapacity):
2810         * runtime/JSFunction.cpp:
2811         (JSC::JSFunction::allocateAndInitializeRareData):
2812         * runtime/JSFunction.h:
2813         (JSC::JSFunction::rareData):
2814         (JSC::JSFunction::allocationStructure): Deleted.
2815         This is no longer used, as all the accesses to the ObjectAllocationProfile go through the rare data.
2816
2817 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2818
2819         DFG should insert Phantoms late using BytecodeKills and block-local OSR availability
2820         https://bugs.webkit.org/show_bug.cgi?id=143735
2821
2822         Reviewed by Geoffrey Garen.
2823         
2824         We've always had bugs arising from the fact that we would MovHint something into a local,
2825         and then fail to keep it alive. We would then try to keep things alive by putting Phantoms
2826         on those Nodes that were MovHinted. But this became increasingly tricky. Given the
2827         sophistication of the transformations we are doing today, this approach is just not sound
2828         anymore.
2829         
2830         This comprehensively fixes these bugs by having the DFG backend automatically insert
2831         Phantoms just before codegen based on bytecode liveness. To make this practical, this also
2832         makes it much faster to query bytecode liveness.
2833         
2834         It's about as perf-neutral as it gets for a change that increases compiler work without
2835         actually optimizing anything. Later changes will remove the old Phantom-preserving logic,
2836         which should then speed us up. I can't really report concrete slow-down numbers because
2837         they are low enough to basically be in the noise. For example, a 20-iteration run of
2838         SunSpider yields "maybe 0.8% slower", whatever that means.
2839
2840         * CMakeLists.txt:
2841         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2842         * JavaScriptCore.xcodeproj/project.pbxproj:
2843         * bytecode/BytecodeLivenessAnalysis.cpp:
2844         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
2845         * bytecode/FullBytecodeLiveness.h:
2846         (JSC::FullBytecodeLiveness::getLiveness):
2847         * bytecode/VirtualRegister.h:
2848         (JSC::VirtualRegister::operator+):
2849         (JSC::VirtualRegister::operator-):
2850         * dfg/DFGForAllKills.h:
2851         (JSC::DFG::forAllLiveNodesAtTail):
2852         (JSC::DFG::forAllKilledOperands):
2853         (JSC::DFG::forAllKilledNodesAtNodeIndex):
2854         * dfg/DFGGraph.cpp:
2855         (JSC::DFG::Graph::isLiveInBytecode):
2856         (JSC::DFG::Graph::localsLiveInBytecode):
2857         * dfg/DFGGraph.h:
2858         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2859         (JSC::DFG::Graph::forAllLiveInBytecode):
2860         * dfg/DFGMayExit.cpp:
2861         (JSC::DFG::mayExit):
2862         * dfg/DFGMovHintRemovalPhase.cpp:
2863         * dfg/DFGNodeType.h:
2864         * dfg/DFGPhantomInsertionPhase.cpp: Added.
2865         (JSC::DFG::performPhantomInsertion):
2866         * dfg/DFGPhantomInsertionPhase.h: Added.
2867         * dfg/DFGPlan.cpp:
2868         (JSC::DFG::Plan::compileInThreadImpl):
2869         * dfg/DFGScoreBoard.h:
2870         (JSC::DFG::ScoreBoard::sortFree):
2871         (JSC::DFG::ScoreBoard::assertClear):
2872         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2873         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2874         * ftl/FTLLowerDFGToLLVM.cpp:
2875         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2876         * tests/stress/phantom-inadequacy.js: Added.
2877         (bar):
2878         (baz):
2879         (foo):
2880
2881 2015-04-23  Filip Pizlo  <fpizlo@apple.com>
2882
2883         Rename HardPhantom to MustGenerate.
2884
2885         Rubber stamped by Geoffrey Garen.
2886         
2887         We are steadily moving towards Phantom just being a backend hack in the DFG. HardPhantom
2888         is more than that; it's a utility for forcing the execution of otherwise killable nodes.
2889         NodeMustGenerate is the flag we use to indicate that something isn't killable. So this
2890         node should just be called MustGenerate.
2891
2892         * dfg/DFGAbstractInterpreterInlines.h:
2893         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2894         * dfg/DFGArgumentsEliminationPhase.cpp:
2895         * dfg/DFGClobberize.h:
2896         (JSC::DFG::clobberize):
2897         * dfg/DFGDCEPhase.cpp:
2898         (JSC::DFG::DCEPhase::run):
2899         * dfg/DFGDoesGC.cpp:
2900         (JSC::DFG::doesGC):
2901         * dfg/DFGFixupPhase.cpp:
2902         (JSC::DFG::FixupPhase::fixupNode):
2903         (JSC::DFG::FixupPhase::tryToRelaxRepresentation):
2904         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2905         (JSC::DFG::IntegerCheckCombiningPhase::insertMustAdd):
2906         * dfg/DFGMayExit.cpp:
2907         (JSC::DFG::mayExit):
2908         * dfg/DFGNode.h:
2909         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2910         * dfg/DFGNodeType.h:
2911         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2912         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2913         * dfg/DFGPhantomCanonicalizationPhase.cpp:
2914         (JSC::DFG::PhantomCanonicalizationPhase::run):
2915         * dfg/DFGPhantomRemovalPhase.cpp:
2916         (JSC::DFG::PhantomRemovalPhase::run):
2917         * dfg/DFGPredictionPropagationPhase.cpp:
2918         (JSC::DFG::PredictionPropagationPhase::propagate):
2919         * dfg/DFGSafeToExecute.h:
2920         (JSC::DFG::safeToExecute):
2921         * dfg/DFGSpeculativeJIT32_64.cpp:
2922         (JSC::DFG::SpeculativeJIT::compile):
2923         * dfg/DFGSpeculativeJIT64.cpp:
2924         (JSC::DFG::SpeculativeJIT::compile):
2925         * dfg/DFGTypeCheckHoistingPhase.cpp:
2926         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2927         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
2928         * dfg/DFGVarargsForwardingPhase.cpp:
2929         * ftl/FTLCapabilities.cpp:
2930         (JSC::FTL::canCompile):
2931         * ftl/FTLLowerDFGToLLVM.cpp:
2932         (JSC::FTL::LowerDFGToLLVM::compileNode):
2933
2934 2015-04-23  Jordan Harband  <ljharb@gmail.com>
2935
2936         Implement `Object.assign`
2937         https://bugs.webkit.org/show_bug.cgi?id=143980
2938
2939         Reviewed by Filip Pizlo.
2940
2941         per https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.assign
2942
2943         * builtins/ObjectConstructor.js: Added.
2944         (assign):
2945         * runtime/CommonIdentifiers.h:
2946         * runtime/JSGlobalObject.cpp:
2947         (JSC::JSGlobalObject::init):
2948         * runtime/ObjectConstructor.cpp:
2949         * runtime/ObjectConstructor.h:
2950
2951 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2952
2953         Unreviewed, fix debug build.
2954
2955         * dfg/DFGGraph.h:
2956         (JSC::DFG::Graph::performSubstitutionForEdge):
2957
2958 2015-04-22  Filip Pizlo  <fpizlo@apple.com>
2959
2960         Nodes should have an optional epoch field
2961         https://bugs.webkit.org/show_bug.cgi?id=144084
2962
2963         Reviewed by Ryosuke Niwa and Mark Lam.
2964         
2965         This makes it easier to do epoch-based analyses on nodes. I plan to do just that in
2966         https://bugs.webkit.org/show_bug.cgi?id=143735. Currently the epoch field is not yet
2967         used.
2968
2969         * dfg/DFGCPSRethreadingPhase.cpp:
2970         (JSC::DFG::CPSRethreadingPhase::canonicalizeGetLocalFor):
2971         * dfg/DFGCSEPhase.cpp:
2972         * dfg/DFGEpoch.h:
2973         (JSC::DFG::Epoch::fromUnsigned):
2974         (JSC::DFG::Epoch::toUnsigned):
2975         * dfg/DFGGraph.cpp:
2976         (JSC::DFG::Graph::clearReplacements):
2977         (JSC::DFG::Graph::clearEpochs):
2978         * dfg/DFGGraph.h:
2979         (JSC::DFG::Graph::performSubstitutionForEdge):
2980         * dfg/DFGNode.h:
2981         (JSC::DFG::Node::Node):
2982         (JSC::DFG::Node::replaceWith):
2983         (JSC::DFG::Node::replacement):
2984         (JSC::DFG::Node::setReplacement):
2985         (JSC::DFG::Node::epoch):
2986         (JSC::DFG::Node::setEpoch):
2987         * dfg/DFGSSAConversionPhase.cpp:
2988         (JSC::DFG::SSAConversionPhase::run):
2989
2990 2015-04-22  Mark Lam  <mark.lam@apple.com>
2991
2992         Fix assertion failure and race condition in Options::dumpSourceAtDFGTime().
2993         https://bugs.webkit.org/show_bug.cgi?id=143898
2994
2995         Reviewed by Filip Pizlo.
2996
2997         CodeBlock::dumpSource() will access SourceCode strings in a way that requires
2998         ref'ing of the underlying StringImpls. This is unsafe to do from arbitrary
2999         compilation threads because StringImpls are not thread safe. As a result, we get
3000         an assertion failure when we run with JSC_dumpSourceAtDFGTime=true on a debug
3001         build.
3002
3003         This patch fixes the issue by only collecting the CodeBlock (and associated info)
3004         into a DeferredSourceDump record while compiling, and stashing it away in a
3005         deferredSourceDump list in the DeferredCompilationCallback object to be dumped
3006         later.
3007
3008         When compilation is done, the callback object will be notified that
3009         compilationDidComplete().  We will dump the SourceCode strings from there. 
3010         Since compilationDidComplete() is guaranteed to only be called on the thread
3011         doing JS execution, it is safe to access the SourceCode strings there and ref
3012         their underlying StringImpls as needed.        
3013
3014         * CMakeLists.txt:
3015         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3016         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3017         * JavaScriptCore.xcodeproj/project.pbxproj:
3018         * bytecode/DeferredCompilationCallback.cpp:
3019         (JSC::DeferredCompilationCallback::compilationDidComplete):
3020         (JSC::DeferredCompilationCallback::sourceDumpInfo):
3021         (JSC::DeferredCompilationCallback::dumpCompiledSources):
3022         * bytecode/DeferredCompilationCallback.h:
3023         * bytecode/DeferredSourceDump.cpp: Added.
3024         (JSC::DeferredSourceDump::DeferredSourceDump):
3025         (JSC::DeferredSourceDump::dump):
3026         * bytecode/DeferredSourceDump.h: Added.
3027         * dfg/DFGByteCodeParser.cpp:
3028         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3029         * dfg/DFGDriver.cpp:
3030         (JSC::DFG::compileImpl):
3031
3032 2015-04-22  Benjamin Poulain  <benjamin@webkit.org>
3033
3034         Implement String.codePointAt()
3035         https://bugs.webkit.org/show_bug.cgi?id=143934
3036
3037         Reviewed by Darin Adler.
3038
3039         This patch adds String.codePointAt() as defined by ES6.
3040         I opted for a C++ implementation for now.
3041
3042         * runtime/StringPrototype.cpp:
3043         (JSC::StringPrototype::finishCreation):
3044         (JSC::codePointAt):
3045         (JSC::stringProtoFuncCodePointAt):
3046
3047 2015-04-22  Mark Lam  <mark.lam@apple.com>
3048
3049         SparseArrayEntry's write barrier owner should be the SparseArrayValueMap.
3050         https://bugs.webkit.org/show_bug.cgi?id=144067
3051
3052         Reviewed by Michael Saboff.
3053
3054         Currently, there are a few places where the JSObject that owns the
3055         SparseArrayValueMap is designated as the owner of the SparseArrayEntry
3056         write barrier.  This is a bug and can result in the GC collecting the
3057         SparseArrayEntry even though it is being referenced by the
3058         SparseArrayValueMap.  This patch fixes the bug.
3059
3060         * runtime/JSObject.cpp:
3061         (JSC::JSObject::enterDictionaryIndexingModeWhenArrayStorageAlreadyExists):
3062         (JSC::JSObject::putIndexedDescriptor):
3063         * tests/stress/sparse-array-entry-update-144067.js: Added.
3064         (useMemoryToTriggerGCs):
3065         (foo):
3066
3067 2015-04-22  Mark Lam  <mark.lam@apple.com>
3068
3069         Give the heap object iterators the ability to return early.
3070         https://bugs.webkit.org/show_bug.cgi?id=144011
3071
3072         Reviewed by Michael Saboff.
3073
3074         JSDollarVMPrototype::isValidCell() uses a heap object iterator to validate
3075         candidate cell pointers, and, when in use, is called a lot more often than
3076         the normal way those iterators are used.  As a result, I see my instrumented
3077         VM killed with a SIGXCPU (CPU time limit exceeded).  This patch gives the
3078         callback functor the ability to tell the iterators to return early when the
3079         functor no longer needs to continue iterating.  With this, my instrumented
3080         VM is useful again for debugging.
3081
3082         Since heap iteration is not something that we do in a typical fast path,
3083         I don't expect this to have any noticeable impact on performance.
3084
3085         I also renamed ObjectAddressCheckFunctor to CellAddressCheckFunctor since
3086         it checks JSCell addresses, not just JSObjects.
3087
3088         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3089         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3090         * JavaScriptCore.xcodeproj/project.pbxproj:
3091         * debugger/Debugger.cpp:
3092         * heap/GCLogging.cpp:
3093         (JSC::LoggingFunctor::operator()):
3094         * heap/Heap.cpp:
3095         (JSC::Zombify::visit):
3096         (JSC::Zombify::operator()):
3097         * heap/HeapStatistics.cpp:
3098         (JSC::StorageStatistics::visit):
3099         (JSC::StorageStatistics::operator()):
3100         * heap/HeapVerifier.cpp:
3101         (JSC::GatherLiveObjFunctor::visit):
3102         (JSC::GatherLiveObjFunctor::operator()):
3103         * heap/MarkedBlock.cpp:
3104         (JSC::SetNewlyAllocatedFunctor::operator()):
3105         * heap/MarkedBlock.h:
3106         (JSC::MarkedBlock::forEachCell):
3107         (JSC::MarkedBlock::forEachLiveCell):
3108         (JSC::MarkedBlock::forEachDeadCell):
3109         * heap/MarkedSpace.h:
3110         (JSC::MarkedSpace::forEachLiveCell):
3111         (JSC::MarkedSpace::forEachDeadCell):
3112         * inspector/agents/InspectorRuntimeAgent.cpp:
3113         (Inspector::TypeRecompiler::visit):
3114         (Inspector::TypeRecompiler::operator()):
3115         * runtime/IterationStatus.h: Added.
3116         * runtime/JSGlobalObject.cpp:
3117         * runtime/VM.cpp:
3118         (JSC::StackPreservingRecompiler::visit):
3119         (JSC::StackPreservingRecompiler::operator()):
3120         * tools/JSDollarVMPrototype.cpp:
3121         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
3122         (JSC::CellAddressCheckFunctor::operator()):
3123         (JSC::JSDollarVMPrototype::isValidCell):
3124         (JSC::ObjectAddressCheckFunctor::ObjectAddressCheckFunctor): Deleted.
3125         (JSC::ObjectAddressCheckFunctor::operator()): Deleted.
3126
3127 2015-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
3128
3129         [[Set]] should be properly executed in JS builtins
3130         https://bugs.webkit.org/show_bug.cgi?id=143996
3131
3132         Reviewed by Geoffrey Garen.
3133
3134         Currently, all assignments in builtins JS code is compiled into put_by_val_direct.
3135         However,
3136
3137         1. Some functions (like Array.from) needs [[Set]]. (but it is now compiled into put_by_val_direct, [[DefineOwnProperty]]).
3138         2. It's different from the default JS behavior.
3139
3140         In this patch, we implement the bytecode intrinsic emitting put_by_val_direct and use it explicitly.
3141         And dropping the current hack for builtins.
3142
3143         * builtins/Array.prototype.js:
3144         (filter):
3145         (map):
3146         (find):
3147         * bytecompiler/BytecodeGenerator.cpp:
3148         (JSC::BytecodeGenerator::emitPutByVal):
3149         * tests/stress/array-fill-put-by-val.js: Added.
3150         (shouldThrow):
3151         (.set get array):
3152         * tests/stress/array-filter-put-by-val-direct.js: Added.
3153         (shouldBe):
3154         (.set get var):
3155         * tests/stress/array-find-does-not-lookup-twice.js: Added.
3156         (shouldBe):
3157         (shouldThrow):
3158         (.get shouldBe):
3159         * tests/stress/array-from-put-by-val-direct.js: Added.
3160         (shouldBe):
3161         (.set get var):
3162         * tests/stress/array-from-set-length.js: Added.
3163         (shouldBe):
3164         (ArrayLike):
3165         (ArrayLike.prototype.set length):
3166         (ArrayLike.prototype.get length):
3167         * tests/stress/array-map-put-by-val-direct.js: Added.
3168         (shouldBe):
3169         (.set get var):
3170
3171 2015-04-22  Basile Clement  <basile_clement@apple.com>
3172  
3173         Don't de-allocate FunctionRareData
3174         https://bugs.webkit.org/show_bug.cgi?id=144000
3175
3176         Reviewed by Michael Saboff.
3177
3178         A function rare data (containing most notably its allocation profile) is currently
3179         freed and re-allocated each time the function's prototype is cleared.
3180         This is not optimal as it means we are invalidating the watchpoint and recompiling the
3181         scope each time the prototype is cleared.
3182
3183         This makes it so that a single rare data is reused, clearing the underlying
3184         ObjectAllocationProfile instead of throwing away the whole rare data on
3185         .prototype updates.
3186
3187         * runtime/FunctionRareData.cpp:
3188         (JSC::FunctionRareData::create):
3189         (JSC::FunctionRareData::finishCreation):
3190         * runtime/FunctionRareData.h:
3191         * runtime/JSFunction.cpp:
3192         (JSC::JSFunction::allocateAndInitializeRareData):
3193         (JSC::JSFunction::initializeRareData):
3194
3195 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3196
3197         Unreviewed, fix 32-bit. Forgot to make this simple change to 32_64 as well.
3198
3199         * dfg/DFGSpeculativeJIT32_64.cpp:
3200         (JSC::DFG::SpeculativeJIT::compile):
3201
3202 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3203
3204         DFG should allow Phantoms after terminals
3205         https://bugs.webkit.org/show_bug.cgi?id=126778
3206
3207         Reviewed by Mark Lam.
3208         
3209         It's important for us to be able to place liveness-marking nodes after nodes that do
3210         things. These liveness-marking nodes are nops. Previously, we disallowed such nodes after
3211         terminals. That made things awkward, especially for Switch and Branch, which may do
3212         things that necessitate liveness markers (for example they might want to use a converted
3213         version of a value rather than the value that was MovHinted). We previously made this
3214         work by disallowing certain optimizations on Switch and Branch, which was probably a bad
3215         thing.
3216         
3217         This changes our IR to allow for the terminal to not be the last node in a block. Asking
3218         for the terminal involves a search. DFG::validate() checks that the nodes after the
3219         terminal are liveness markers that have no effects or checks.
3220         
3221         This is perf-neutral but will allow more optimizations in the future. It will also make
3222         it cleaner to fix https://bugs.webkit.org/show_bug.cgi?id=143735.
3223
3224         * dfg/DFGBasicBlock.cpp:
3225         (JSC::DFG::BasicBlock::replaceTerminal):
3226         * dfg/DFGBasicBlock.h:
3227         (JSC::DFG::BasicBlock::findTerminal):
3228         (JSC::DFG::BasicBlock::terminal):
3229         (JSC::DFG::BasicBlock::insertBeforeTerminal):
3230         (JSC::DFG::BasicBlock::numSuccessors):
3231         (JSC::DFG::BasicBlock::successor):
3232         (JSC::DFG::BasicBlock::successorForCondition):
3233         (JSC::DFG::BasicBlock::successors):
3234         (JSC::DFG::BasicBlock::last): Deleted.
3235         (JSC::DFG::BasicBlock::takeLast): Deleted.
3236         (JSC::DFG::BasicBlock::insertBeforeLast): Deleted.
3237         (JSC::DFG::BasicBlock::SuccessorsIterable::SuccessorsIterable): Deleted.
3238         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::iterator): Deleted.
3239         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator*): Deleted.
3240         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator++): Deleted.
3241         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator==): Deleted.
3242         (JSC::DFG::BasicBlock::SuccessorsIterable::iterator::operator!=): Deleted.
3243         (JSC::DFG::BasicBlock::SuccessorsIterable::begin): Deleted.
3244         (JSC::DFG::BasicBlock::SuccessorsIterable::end): Deleted.
3245         * dfg/DFGBasicBlockInlines.h:
3246         (JSC::DFG::BasicBlock::appendNonTerminal):
3247         (JSC::DFG::BasicBlock::replaceTerminal):
3248         * dfg/DFGByteCodeParser.cpp:
3249         (JSC::DFG::ByteCodeParser::addToGraph):
3250         (JSC::DFG::ByteCodeParser::inlineCall):
3251         (JSC::DFG::ByteCodeParser::handleInlining):
3252         (JSC::DFG::ByteCodeParser::parseBlock):
3253         (JSC::DFG::ByteCodeParser::linkBlock):
3254         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3255         * dfg/DFGCFGSimplificationPhase.cpp:
3256         (JSC::DFG::CFGSimplificationPhase::run):
3257         (JSC::DFG::CFGSimplificationPhase::convertToJump):
3258         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
3259         * dfg/DFGCPSRethreadingPhase.cpp:
3260         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
3261         * dfg/DFGCommon.h:
3262         (JSC::DFG::NodeAndIndex::NodeAndIndex):
3263         (JSC::DFG::NodeAndIndex::operator!):
3264         * dfg/DFGFixupPhase.cpp:
3265         (JSC::DFG::FixupPhase::fixupBlock):
3266         (JSC::DFG::FixupPhase::fixupNode):
3267         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock):
3268         (JSC::DFG::FixupPhase::clearPhantomsAtEnd): Deleted.
3269         * dfg/DFGForAllKills.h:
3270         (JSC::DFG::forAllLiveNodesAtTail):
3271         * dfg/DFGGraph.cpp:
3272         (JSC::DFG::Graph::terminalsAreValid):
3273         (JSC::DFG::Graph::dumpBlockHeader):
3274         * dfg/DFGGraph.h:
3275         * dfg/DFGInPlaceAbstractState.cpp:
3276         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
3277         * dfg/DFGLICMPhase.cpp:
3278         (JSC::DFG::LICMPhase::run):
3279         (JSC::DFG::LICMPhase::attemptHoist):
3280         * dfg/DFGMovHintRemovalPhase.cpp:
3281         * dfg/DFGNode.h:
3282         (JSC::DFG::Node::SuccessorsIterable::SuccessorsIterable):
3283         (JSC::DFG::Node::SuccessorsIterable::iterator::iterator):
3284         (JSC::DFG::Node::SuccessorsIterable::iterator::operator*):
3285         (JSC::DFG::Node::SuccessorsIterable::iterator::operator++):
3286         (JSC::DFG::Node::SuccessorsIterable::iterator::operator==):
3287         (JSC::DFG::Node::SuccessorsIterable::iterator::operator!=):
3288         (JSC::DFG::Node::SuccessorsIterable::begin):
3289         (JSC::DFG::Node::SuccessorsIterable::end):
3290         (JSC::DFG::Node::successors):
3291         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3292         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
3293         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
3294         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
3295         * dfg/DFGPhantomRemovalPhase.cpp:
3296         (JSC::DFG::PhantomRemovalPhase::run):
3297         * dfg/DFGPutStackSinkingPhase.cpp:
3298         * dfg/DFGSSAConversionPhase.cpp:
3299         (JSC::DFG::SSAConversionPhase::run):
3300         * dfg/DFGSpeculativeJIT.h:
3301         (JSC::DFG::SpeculativeJIT::detectPeepHoleBranch):
3302         * dfg/DFGSpeculativeJIT32_64.cpp:
3303         (JSC::DFG::SpeculativeJIT::compile):
3304         * dfg/DFGSpeculativeJIT64.cpp:
3305         (JSC::DFG::SpeculativeJIT::compile):
3306         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
3307         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
3308         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3309         (JSC::DFG::TierUpCheckInjectionPhase::run):
3310         * dfg/DFGValidate.cpp:
3311         (JSC::DFG::Validate::validate):
3312         * ftl/FTLLowerDFGToLLVM.cpp:
3313         (JSC::FTL::LowerDFGToLLVM::compileNode):
3314         * tests/stress/closure-call-exit.js: Added.
3315         (foo):
3316
3317 2015-04-21  Basile Clement  <basile_clement@apple.com>
3318
3319         PhantomNewObject should be marked NodeMustGenerate
3320         https://bugs.webkit.org/show_bug.cgi?id=143974
3321
3322         Reviewed by Filip Pizlo.
3323
3324         * dfg/DFGNode.h:
3325         (JSC::DFG::Node::convertToPhantomNewObject):
3326         Was not properly marking NodeMustGenerate when converting.
3327
3328 2015-04-21  Filip Pizlo  <fpizlo@apple.com>
3329
3330         DFG Call/ConstructForwardVarargs fails to restore the stack pointer
3331         https://bugs.webkit.org/show_bug.cgi?id=144007
3332
3333         Reviewed by Mark Lam.
3334         
3335         We were conditioning the stack pointer restoration on isVarargs, but we also need to do it
3336         if isForwardVarargs.
3337
3338         * dfg/DFGSpeculativeJIT32_64.cpp:
3339         (JSC::DFG::SpeculativeJIT::emitCall):