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