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