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