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