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