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