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