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