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