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