[CMake] Ignore warnings in system headers
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-18  Michael Catanzaro  <mcatanzaro@igalia.com>
2
3         [CMake] Ignore warnings in system headers
4         https://bugs.webkit.org/show_bug.cgi?id=144747
5
6         Reviewed by Darin Adler.
7
8         Separate include directories into WebKit project includes and system includes. Suppress all
9         warnings from headers in system include directories using the SYSTEM argument to
10         the include_directories command.
11
12         * CMakeLists.txt:
13         * PlatformGTK.cmake:
14
15 2015-05-18  Skachkov Alexandr  <gskachkov@gmail.com>
16
17         [ES6] Arrow function syntax. Feature flag for arrow function
18         https://bugs.webkit.org/show_bug.cgi?id=145108
19
20         Reviewed by Ryosuke Niwa.
21
22         Added feature flag ENABLE_ES6_ARROWFUNCTION_SYNTAX for arrow function
23
24         * Configurations/FeatureDefines.xcconfig:
25         
26 2015-05-18  Benjamin Poulain  <benjamin@webkit.org>
27
28         [JSC] When entering a CheckTierUp without OSREntry, force the CheckTierUp for the outer loops with OSR Entry
29         https://bugs.webkit.org/show_bug.cgi?id=145092
30
31         Reviewed by Filip Pizlo.
32
33         When we have a hot loop without OSR Entry inside a slower loop that support OSR Entry,
34         we get the inside loop driving the tierUpCounter and we have very little chance of
35         doing a CheckTierUp on the outer loop. In turn, this give almost no opportunity to tier
36         up in the outer loop and OSR Enter there.
37
38         This patches changes CheckTierUp to force its outer loops to do a CheckTierUp themselves.
39
40         To do that, CheckTierUp sets a flag "nestedTriggerIsSet" to force the outer loop to
41         enter their CheckTierUp regardless of the tier-up counter.
42
43         * bytecode/ExecutionCounter.cpp:
44         (JSC::ExecutionCounter<countingVariant>::setThreshold):
45         This is somewhat unrelated. This assertion is incorrect because it relies on
46         m_counter, which changes on an other thread.
47
48         I have hit it a couple of times with this patch because we are a bit more aggressive
49         on CheckTierUp. What happens is:
50         1) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() first checks
51            hasCrossedThreshold(), and it is false.
52         2) On the main thread, the hot loops keeps running and the counter becomes large
53            enough to cross the threshold.
54         3) ExecutionCounter<countingVariant>::checkIfThresholdCrossedAndSet() runs the next
55            test, setThreshold(), where the assertion is. Since the counter is now large enough,
56            the assertion fails.
57
58         * dfg/DFGAbstractInterpreterInlines.h:
59         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
60         * dfg/DFGClobberize.h:
61         (JSC::DFG::clobberize):
62         * dfg/DFGDoesGC.cpp:
63         (JSC::DFG::doesGC):
64         * dfg/DFGFixupPhase.cpp:
65         (JSC::DFG::FixupPhase::fixupNode):
66
67         * dfg/DFGJITCode.h:
68         I used a uint8_t instead of a boolean to make the code generation clearer
69         in DFGSpeculativeJIT64.
70
71         * dfg/DFGNodeType.h:
72         * dfg/DFGOperations.cpp:
73         * dfg/DFGOperations.h:
74
75         * dfg/DFGPredictionPropagationPhase.cpp:
76         (JSC::DFG::PredictionPropagationPhase::propagate):
77         This is a bit annoying: we have the NaturalLoops analysis that provides us
78         everything we need to know about loops, but the TierUpCheck are conservative
79         and set on LoopHint.
80
81         To make the two work together, we first find all the CheckTierUp that cannot
82         OSR enter and we keep a list of all the natural loops containing them.
83
84         Then we do a second pass over the LoopHints, get their NaturalLoop, and check
85         if it contains a loop that cannot OSR enter.
86
87         * dfg/DFGSafeToExecute.h:
88         (JSC::DFG::safeToExecute):
89         * dfg/DFGSpeculativeJIT32_64.cpp:
90         (JSC::DFG::SpeculativeJIT::compile):
91         * dfg/DFGSpeculativeJIT64.cpp:
92         (JSC::DFG::SpeculativeJIT::compile):
93         * dfg/DFGTierUpCheckInjectionPhase.cpp:
94         (JSC::DFG::TierUpCheckInjectionPhase::run):
95         (JSC::DFG::TierUpCheckInjectionPhase::canOSREnterAtLoopHint):
96
97 2015-05-18  Filip Pizlo  <fpizlo@apple.com>
98
99         Add a Int-or-Boolean speculation to Branch
100         https://bugs.webkit.org/show_bug.cgi?id=145134
101
102         Reviewed by Benjamin Poulain.
103         
104         After https://bugs.webkit.org/show_bug.cgi?id=126778 we no longer have a reason not to do the
105         int-or-boolean optimization that we already do everywhere else.
106
107         * dfg/DFGFixupPhase.cpp:
108         (JSC::DFG::FixupPhase::fixupNode):
109
110 2015-05-18  Andreas Kling  <akling@apple.com>
111
112         [JSC] Speed up URL encode/decode by using bitmaps instead of strchr().
113         <https://webkit.org/b/145115>
114
115         Reviewed by Anders Carlsson.
116
117         We were calling strchr() for every character when doing URL encoding/decoding and it stood out
118         like a sore O(n) thumb in Instruments. Optimize this by using a Bitmap<256> instead.
119
120         5.5% progression on Kraken/stanford-crypto-sha256-iterative.
121
122         * runtime/JSGlobalObjectFunctions.cpp:
123         (JSC::makeCharacterBitmap):
124         (JSC::encode):
125         (JSC::decode):
126         (JSC::globalFuncDecodeURI):
127         (JSC::globalFuncDecodeURIComponent):
128         (JSC::globalFuncEncodeURI):
129         (JSC::globalFuncEncodeURIComponent):
130         (JSC::globalFuncEscape):
131
132 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
133
134         Do not use fastMallocGoodSize anywhere
135         https://bugs.webkit.org/show_bug.cgi?id=145103
136
137         Reviewed by Michael Saboff.
138
139         * assembler/AssemblerBuffer.h:
140         (JSC::AssemblerData::AssemblerData):
141         (JSC::AssemblerData::grow):
142
143 2015-05-17  Benjamin Poulain  <benjamin@webkit.org>
144
145         [JSC] Make StringRecursionChecker faster in the simple cases without any recursion
146         https://bugs.webkit.org/show_bug.cgi?id=145102
147
148         Reviewed by Darin Adler.
149
150         In general, the array targeted by Array.toString() or Array.join() are pretty
151         simple. In those simple cases, we spend as much time in StringRecursionChecker
152         as we do on the actual operation.
153
154         The reason for this is the HashSet stringRecursionCheckVisitedObjects used
155         to detect recursion. We are constantly adding and removing objects which
156         dirty buckets and force constant rehash.
157
158         This patch adds a simple shortcut for those simple case: in addition to the HashSet,
159         we keep a pointer to the root object of the recursion.
160         In the vast majority of cases, we no longer touch the HashSet at all.
161
162         This patch is a 12% progression on the overall score of ArrayWeighted.
163
164         * runtime/StringRecursionChecker.h:
165         (JSC::StringRecursionChecker::performCheck):
166         (JSC::StringRecursionChecker::~StringRecursionChecker):
167         * runtime/VM.h:
168
169 2015-05-17  Filip Pizlo  <fpizlo@apple.com>
170
171         Insert store barriers late so that IR transformations don't have to worry about them
172         https://bugs.webkit.org/show_bug.cgi?id=145015
173
174         Reviewed by Geoffrey Garen.
175         
176         We have had three kinds of bugs with store barriers. For the sake of discussion we say
177         that a store barrier is needed when we have something like:
178         
179             base.field = value
180         
181         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
182           This might happen if we prove value to be a non-cell even though in the FixupPhase it
183           wasn't predicted non-cell.
184         
185         - We sometimes have a barrier in the wrong place after object allocation sinking. We
186           might sink an allocation to just above the store, but that puts it just after the
187           StoreBarrier that FixupPhase inserted.
188         
189         - We don't remove redundant barriers across basic blocks.
190         
191         This comprehensively fixes these issues by doing store barrier insertion late, and
192         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
193         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
194         base is in the current GC epoch (i.e. was the last object that we allocated or had a
195         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
196         always been allocated before base). We do conservative things when merging epoch state
197         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
198         queries AI to determine what type we've proved about value, and avoids barriers when
199         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
200         the likelihood that this AI-based removal is effective.
201         
202         Rolling back in after fixing some debug build test failures.
203
204         * CMakeLists.txt:
205         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
206         * JavaScriptCore.xcodeproj/project.pbxproj:
207         * dfg/DFGBlockMap.h:
208         (JSC::DFG::BlockMap::at):
209         * dfg/DFGConstantFoldingPhase.cpp:
210         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
211         * dfg/DFGEpoch.h:
212         (JSC::DFG::Epoch::operator<):
213         (JSC::DFG::Epoch::operator>):
214         (JSC::DFG::Epoch::operator<=):
215         (JSC::DFG::Epoch::operator>=):
216         * dfg/DFGFixupPhase.cpp:
217         (JSC::DFG::FixupPhase::fixupNode):
218         (JSC::DFG::FixupPhase::speculateForBarrier):
219         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
220         * dfg/DFGPlan.cpp:
221         (JSC::DFG::Plan::compileInThreadImpl):
222         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
223         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
224         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
225         (JSC::DFG::performFastStoreBarrierInsertion):
226         (JSC::DFG::performGlobalStoreBarrierInsertion):
227         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
228         * ftl/FTLOperations.cpp:
229         (JSC::FTL::operationMaterializeObjectInOSR): Fix an unrelated debug-only bug.
230         * tests/stress/load-varargs-then-inlined-call-and-exit.js: Test for that debug-only bug.
231         * tests/stress/load-varargs-then-inlined-call-and-exit-strict.js: Strict version of that test.
232
233 2015-05-16  Commit Queue  <commit-queue@webkit.org>
234
235         Unreviewed, rolling out r184415.
236         https://bugs.webkit.org/show_bug.cgi?id=145096
237
238         Broke several tests (Requested by msaboff on #webkit).
239
240         Reverted changeset:
241
242         "Insert store barriers late so that IR transformations don't
243         have to worry about them"
244         https://bugs.webkit.org/show_bug.cgi?id=145015
245         http://trac.webkit.org/changeset/184415
246
247 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
248
249         Insert store barriers late so that IR transformations don't have to worry about them
250         https://bugs.webkit.org/show_bug.cgi?id=145015
251
252         Reviewed by Geoffrey Garen.
253         
254         We have had three kinds of bugs with store barriers. For the sake of discussion we say
255         that a store barrier is needed when we have something like:
256         
257             base.field = value
258         
259         - We sometimes fail to realize that we could remove a barrier when value is a non-cell.
260           This might happen if we prove value to be a non-cell even though in the FixupPhase it
261           wasn't predicted non-cell.
262         
263         - We sometimes have a barrier in the wrong place after object allocation sinking. We
264           might sink an allocation to just above the store, but that puts it just after the
265           StoreBarrier that FixupPhase inserted.
266         
267         - We don't remove redundant barriers across basic blocks.
268         
269         This comprehensively fixes these issues by doing store barrier insertion late, and
270         removing the store barrier elision phase. Store barrier insertion uses an epoch-based
271         algorithm to determine when stores need barriers. Briefly, a barrier is not needed if
272         base is in the current GC epoch (i.e. was the last object that we allocated or had a
273         barrier since last GC) or if base has a newer GC epoch than value (i.e. value would have
274         always been allocated before base). We do conservative things when merging epoch state
275         between basic blocks, and we only do such inter-block removal in the FTL. FTL also
276         queries AI to determine what type we've proved about value, and avoids barriers when
277         value is not a cell. FixupPhase still inserts type checks on some stores, to maximize
278         the likelihood that this AI-based removal is effective.
279
280         * CMakeLists.txt:
281         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
282         * JavaScriptCore.xcodeproj/project.pbxproj:
283         * dfg/DFGBlockMap.h:
284         (JSC::DFG::BlockMap::at):
285         * dfg/DFGConstantFoldingPhase.cpp:
286         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
287         * dfg/DFGEpoch.h:
288         (JSC::DFG::Epoch::operator<):
289         (JSC::DFG::Epoch::operator>):
290         (JSC::DFG::Epoch::operator<=):
291         (JSC::DFG::Epoch::operator>=):
292         * dfg/DFGFixupPhase.cpp:
293         (JSC::DFG::FixupPhase::fixupNode):
294         (JSC::DFG::FixupPhase::speculateForBarrier):
295         (JSC::DFG::FixupPhase::insertStoreBarrier): Deleted.
296         * dfg/DFGPlan.cpp:
297         (JSC::DFG::Plan::compileInThreadImpl):
298         * dfg/DFGStoreBarrierElisionPhase.cpp: Removed.
299         * dfg/DFGStoreBarrierElisionPhase.h: Removed.
300         * dfg/DFGStoreBarrierInsertionPhase.cpp: Added.
301         (JSC::DFG::performFastStoreBarrierInsertion):
302         (JSC::DFG::performGlobalStoreBarrierInsertion):
303         * dfg/DFGStoreBarrierInsertionPhase.h: Added.
304
305 2015-05-15  Benjamin Poulain  <bpoulain@apple.com>
306
307         [ARM64] Do not fail branchConvertDoubleToInt32 when the result is zero and not negative zero
308         https://bugs.webkit.org/show_bug.cgi?id=144976
309
310         Reviewed by Michael Saboff.
311
312         Failing the conversion on zero is pretty dangerous as we discovered on x86.
313
314         This patch does not really impact performance significantly because
315         r184220 removed the zero checks from Kraken. This patch is just to be
316         on the safe side for cases not covered by existing benchmarks.
317
318         * assembler/MacroAssemblerARM64.h:
319         (JSC::MacroAssemblerARM64::branchConvertDoubleToInt32):
320
321 2015-05-15  Sungmann Cho  <sungmann.cho@navercorp.com>
322
323         Remove unnecessary forward declarations in PropertyNameArray.h.
324         https://bugs.webkit.org/show_bug.cgi?id=145058
325
326         Reviewed by Andreas Kling.
327
328         No new tests, no behavior change.
329
330         * runtime/PropertyNameArray.h:
331
332 2015-05-15  Mark Lam  <mark.lam@apple.com>
333
334         JSArray::setLength() should reallocate instead of zero-filling if the reallocation would be small enough.
335         https://bugs.webkit.org/show_bug.cgi?id=144622
336
337         Reviewed by Geoffrey Garen.
338
339         When setting the array to a new length that is shorter, we now check if it is worth
340         just making a new butterfly instead of clearing out the slots in the old butterfly
341         that resides beyond the new length.  If so, we will make a new butterfly instead.
342
343         There is no perf differences in the benchmark results.  However, this does benefit
344         the perf of pathological cases where we need to shorten the length of a very large
345         array, as is the case in tests/mozilla/js1_5/Array/regress-101964.js.  With this
346         patch, we can expect that test to complete in a short time again.
347
348         * runtime/JSArray.cpp:
349         (JSC::JSArray::setLength):
350         * runtime/JSObject.cpp:
351         (JSC::JSObject::reallocateAndShrinkButterfly):
352         - makes a new butterfly with a new shorter length.
353         * runtime/JSObject.h:
354         * tests/mozilla/js1_5/Array/regress-101964.js:
355         - Undo this test change since this patch will prevent us from spending a lot of time
356           clearing a large butterfly.
357
358 2015-05-15  Basile Clement  <basile_clement@apple.com>
359
360         DFGLICMPhase shouldn't create NodeOrigins with forExit but without semantic
361         https://bugs.webkit.org/show_bug.cgi?id=145062
362
363         Reviewed by Filip Pizlo.
364
365         We assert in various places (including NodeOrigin::isSet()) that a
366         NodeOrigin's semantic and forExit must be either both set, or both
367         unset.  However, LICM'ing a node with unset NodeOrigin would only set
368         forExit, and leave semantic unset. This can for instance happen when a
369         Phi node is constant-folded into a JSConstant, which in turn gets
370         LICM'd.
371
372         This patch changes DFGLICMPhase to set the NodeOrigin's semantic in
373         addition to its forExit if semantic was previously unset.
374
375         It also adds two validators to DFGValidate.cpp:
376          - In both SSA and CPS form, a NodeOrigin semantic and forExit must be either both set or both unset
377          - In CPS form, all nodes must have a set NodeOrigin forExit (this is
378            the CPS counterpart to the SSA validator that checks that all nodes
379            must have a set NodeOrigin except possibly for a continuous chunk of
380            nodes at the top of a block)
381
382         * dfg/DFGLICMPhase.cpp:
383         (JSC::DFG::LICMPhase::attemptHoist):
384         * dfg/DFGValidate.cpp:
385         (JSC::DFG::Validate::validate):
386         (JSC::DFG::Validate::validateCPS):
387
388 2015-05-15  Filip Pizlo  <fpizlo@apple.com>
389
390         Unreviewed, remove an unused declaration.
391
392         * dfg/DFGSpeculativeJIT.h:
393
394 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
395
396         Remove unused constant-base and constant-value store barrier code in the DFG
397         https://bugs.webkit.org/show_bug.cgi?id=145039
398
399         Reviewed by Andreas Kling.
400         
401         Just killing dead code.
402
403         * dfg/DFGSpeculativeJIT.cpp:
404         (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
405         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
406         * dfg/DFGSpeculativeJIT.h:
407         * dfg/DFGSpeculativeJIT32_64.cpp:
408         (JSC::DFG::SpeculativeJIT::writeBarrier):
409         * dfg/DFGSpeculativeJIT64.cpp:
410         (JSC::DFG::SpeculativeJIT::writeBarrier):
411
412 2015-05-15  Alexandr Skachkov  <gskachkov@gmail.com>
413
414         Fix typo in function name parseFunctionParamters -> parseFunctionParameters
415         https://bugs.webkit.org/show_bug.cgi?id=145040
416
417         Reviewed by Mark Lam.
418
419         * parser/Parser.h:
420         * parser/Parser.cpp:
421
422 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
423
424         Remove StoreBarrierWithNullCheck, nobody ever generates this.
425         
426         Rubber stamped by Benjamin Poulain and Michael Saboff.
427
428         If we did bring something like this back in the future, we would just use UntypedUse instead
429         of CellUse to indicate that this is what we want.
430
431         * dfg/DFGAbstractInterpreterInlines.h:
432         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
433         * dfg/DFGClobberize.h:
434         (JSC::DFG::clobberize):
435         * dfg/DFGDoesGC.cpp:
436         (JSC::DFG::doesGC):
437         * dfg/DFGFixupPhase.cpp:
438         (JSC::DFG::FixupPhase::fixupNode):
439         * dfg/DFGNode.h:
440         (JSC::DFG::Node::isStoreBarrier):
441         * dfg/DFGNodeType.h:
442         * dfg/DFGObjectAllocationSinkingPhase.cpp:
443         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
444         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
445         * dfg/DFGPredictionPropagationPhase.cpp:
446         (JSC::DFG::PredictionPropagationPhase::propagate):
447         * dfg/DFGSafeToExecute.h:
448         (JSC::DFG::safeToExecute):
449         * dfg/DFGSpeculativeJIT.cpp:
450         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
451         * dfg/DFGSpeculativeJIT32_64.cpp:
452         (JSC::DFG::SpeculativeJIT::compile):
453         * dfg/DFGSpeculativeJIT64.cpp:
454         (JSC::DFG::SpeculativeJIT::compile):
455         * ftl/FTLCapabilities.cpp:
456         (JSC::FTL::canCompile):
457         * ftl/FTLLowerDFGToLLVM.cpp:
458         (JSC::FTL::LowerDFGToLLVM::compileNode):
459         (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): Deleted.
460
461 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
462
463         PutGlobalVar should reference the global object it's storing into
464         https://bugs.webkit.org/show_bug.cgi?id=145036
465
466         Reviewed by Michael Saboff.
467         
468         This makes it easier to reason about store barrier insertion and elimination. This changes
469         the format of PutGlobalVar so that child1 is the global object and child2 is the value.
470         Previously it just had child1, and that was the value.
471
472         * dfg/DFGByteCodeParser.cpp:
473         (JSC::DFG::ByteCodeParser::parseBlock):
474         * dfg/DFGClobberize.h:
475         (JSC::DFG::clobberize):
476         * dfg/DFGFixupPhase.cpp:
477         (JSC::DFG::FixupPhase::fixupNode):
478         * dfg/DFGSpeculativeJIT32_64.cpp:
479         (JSC::DFG::SpeculativeJIT::compile):
480         * dfg/DFGSpeculativeJIT64.cpp:
481         (JSC::DFG::SpeculativeJIT::compile):
482         * ftl/FTLLowerDFGToLLVM.cpp:
483         (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
484
485 2015-05-14  Michael Catanzaro  <mcatanzaro@igalia.com>
486
487         [CMake] Error out when ruby is too old
488         https://bugs.webkit.org/show_bug.cgi?id=145014
489
490         Reviewed by Martin Robinson.
491
492         Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
493         CMakeLists.txt instead.
494
495         * CMakeLists.txt:
496
497 2015-05-12  Basile Clement  <basile_clement@apple.com>
498
499         Enforce options coherency
500         https://bugs.webkit.org/show_bug.cgi?id=144921
501
502         Reviewed by Mark Lam.
503
504         JavaScriptCore should be failing early when the options are set in such
505         a way that we don't have a meaningful way to execute JavaScript, rather
506         than failing for obscure reasons at some point during execution.
507
508         This patch adds a new function that checks whether the options are set
509         in a coherent way, and makes JSC::Options::initialize() crash when the
510         environment enforces incoherent options.
511         Client applications able to add or change additional options are
512         responsible to check for coherency again before starting to actually
513         execute JavaScript, if any additional options have been set. This is
514         implemented for the jsc executable in this patch.
515
516         * jsc.cpp:
517         (CommandLine::parseArguments):
518         * runtime/Options.cpp:
519         (JSC::Options::initialize):
520         (JSC::Options::ensureOptionsAreCoherent): Added.
521         * runtime/Options.h:
522         (JSC::Options::ensureOptionsAreCoherent): Added.
523
524 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
525
526         REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
527         https://bugs.webkit.org/show_bug.cgi?id=145019
528
529         Reviewed by Ryosuke Niwa.
530
531         Attempt to fix compile errors in EFL ARM buildbots.
532         By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
533         unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
534
535         * runtime/JSTemplateRegistryKey.cpp:
536         * runtime/TemplateRegistry.cpp:
537
538 2015-05-14  Alexandr Skachkov  <gskachkov@gmail.com>
539
540         Small refactoring before implementation of the ES6 arrow function.
541         https://bugs.webkit.org/show_bug.cgi?id=144954
542
543         Reviewed by Ryosuke Niwa.
544
545         * parser/Parser.h:
546         * parser/Parser.cpp:
547
548 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
549
550         REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
551         https://bugs.webkit.org/show_bug.cgi?id=145013
552
553         Reviewed by Filip Pizlo.
554
555         Fix the regression introduced by r184337.
556
557         1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
558            JSDestructibleObject::s_info.
559
560         2. The first register argument of BytecodeGenerator::emitNode
561            should be a referenced register if it is a temporary register.
562
563         * bytecompiler/NodesCodegen.cpp:
564         (JSC::TaggedTemplateNode::emitBytecode):
565         * runtime/JSTemplateRegistryKey.cpp:
566
567 2015-05-14  Andreas Kling  <akling@apple.com>
568
569         String.prototype.split() should create efficient substrings.
570         <https://webkit.org/b/144985>
571         <rdar://problem/20949344>
572
573         Reviewed by Geoffrey Garen.
574
575         Teach split() how to make substring JSStrings instead of relying on StringImpl's
576         substring sharing mechanism. The optimization works by deferring the construction
577         of a StringImpl until the substring's value is actually needed.
578
579         This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
580         Out of ~70000 substrings created by split(), only ~2000 of them get reified.
581
582         * runtime/StringPrototype.cpp:
583         (JSC::jsSubstring):
584         (JSC::splitStringByOneCharacterImpl):
585         (JSC::stringProtoFuncSplit):
586
587 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
588
589         Change the status of ES6 tagged templates to Done in features.json
590         https://bugs.webkit.org/show_bug.cgi?id=145003
591
592         Reviewed by Benjamin Poulain.
593
594         Now it's implemented in r184337.
595
596         * features.json:
597
598 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
599
600         Introduce SymbolType into SpeculativeTypes
601         https://bugs.webkit.org/show_bug.cgi?id=142651
602
603         Reviewed by Filip Pizlo.
604
605         Introduce SpecSymbol type into speculative types.
606         Previously symbol type is categorized into SpecCellOther.
607         But SpecCellOther is not intended to be used for such cells.
608
609         This patch just introduces SpecSymbol.
610         It represents the type of target value is definitely the symbol type.
611         It is the part of SpecCell.
612
613         In this patch, we do not introduce SymbolUse tracking.
614         It will be added in the separate patch.
615
616         * bytecode/SpeculatedType.cpp:
617         (JSC::dumpSpeculation):
618         (JSC::speculationFromStructure):
619         * bytecode/SpeculatedType.h:
620         (JSC::isSymbolSpeculation):
621         * dfg/DFGAbstractInterpreterInlines.h:
622         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
623         * dfg/DFGAbstractValue.cpp:
624         (JSC::DFG::AbstractValue::setType):
625         * dfg/DFGConstantFoldingPhase.cpp:
626         (JSC::DFG::ConstantFoldingPhase::foldConstants):
627         * tests/stress/typeof-symbol.js: Added.
628
629 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
630
631         [ES6] Implement tagged templates
632         https://bugs.webkit.org/show_bug.cgi?id=143183
633
634         Reviewed by Oliver Hunt.
635
636         This patch implements ES6 tagged templates.
637         In tagged templates, the function takes the template object.
638
639         The template object contains the raw and cooked template strings,
640         so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
641         While tagged templates require the both strings, the template literal only requires
642         the cooked strings. So when tokenizing under the template literal context,
643         we only builds the cooked strings.
644
645         As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
646         The template objects is cached. And every time we evaluate the same tagged templates,
647         the same (cached) template objects are used.
648         Since the spec freezes this template objects completely,
649         we cannot attach some properties to it.
650         So we can say that it behaves as if the template objects are the primitive values (like JSString).
651         Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
652         As the result, when there is no reference to the template object, we can garbage collect it
653         because the user has no way to test that the newly created template object does not equal
654         to the already collected template object.
655
656         So, to implement tagged templates, we implement the following components.
657
658         1. JSTemplateRegistryKey
659         It holds the template registry key and it does not exposed to users.
660         TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
661         When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
662         we use this JSTemplateRegistryKey as a key to the map and look up the template object from
663         TemplateRegistry.
664         JSTemplateRegistryKey is created at the bytecode compiling time and
665         stored in the CodeBlock as like as JSString content values.
666
667         2. TemplateRegistry
668         This manages the cached template objects.
669         It holds the weak map (JSTemplateRegistryKey -> the template object).
670         The template object is weakly referenced.
671         So if there is no reference to the template object,
672         the template object is automatically GC-ed.
673         When looking up the template object, it searches the cached template object.
674         If it is found, it is returned to the users.
675         If there is no cached template objects, it creates the new template object and
676         stores it with the given template registry key.
677
678         * CMakeLists.txt:
679         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
680         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
681         * JavaScriptCore.xcodeproj/project.pbxproj:
682         * bytecompiler/BytecodeGenerator.cpp:
683         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
684         (JSC::BytecodeGenerator::emitGetTemplateObject):
685         * bytecompiler/BytecodeGenerator.h:
686         * bytecompiler/NodesCodegen.cpp:
687         (JSC::TaggedTemplateNode::emitBytecode):
688         (JSC::TemplateLiteralNode::emitBytecode): Deleted.
689         * parser/ASTBuilder.h:
690         (JSC::ASTBuilder::createTaggedTemplate):
691         (JSC::ASTBuilder::createTemplateLiteral): Deleted.
692         * parser/Lexer.cpp:
693         (JSC::Lexer<T>::setCode):
694         (JSC::Lexer<T>::parseTemplateLiteral):
695         (JSC::Lexer<T>::lex):
696         (JSC::Lexer<T>::scanTrailingTemplateString):
697         (JSC::Lexer<T>::clear):
698         * parser/Lexer.h:
699         (JSC::Lexer<T>::makeEmptyIdentifier):
700         * parser/NodeConstructors.h:
701         (JSC::TaggedTemplateNode::TaggedTemplateNode):
702         (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
703         * parser/Nodes.h:
704         (JSC::TemplateLiteralNode::templateStrings):
705         (JSC::TemplateLiteralNode::templateExpressions):
706         (JSC::TaggedTemplateNode::templateLiteral):
707         * parser/Parser.cpp:
708         (JSC::Parser<LexerType>::parseTemplateString):
709         (JSC::Parser<LexerType>::parseTemplateLiteral):
710         (JSC::Parser<LexerType>::parsePrimaryExpression):
711         (JSC::Parser<LexerType>::parseMemberExpression):
712         * parser/Parser.h:
713         * parser/ParserArena.h:
714         (JSC::IdentifierArena::makeEmptyIdentifier):
715         * parser/SyntaxChecker.h:
716         (JSC::SyntaxChecker::createTaggedTemplate):
717         (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
718         * runtime/CommonIdentifiers.h:
719         * runtime/JSGlobalObject.cpp:
720         (JSC::getTemplateObject):
721         (JSC::JSGlobalObject::JSGlobalObject):
722         (JSC::JSGlobalObject::init):
723         * runtime/JSGlobalObject.h:
724         (JSC::JSGlobalObject::templateRegistry):
725         * runtime/JSTemplateRegistryKey.cpp: Added.
726         (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
727         (JSC::JSTemplateRegistryKey::create):
728         (JSC::JSTemplateRegistryKey::destroy):
729         * runtime/JSTemplateRegistryKey.h: Added.
730         * runtime/ObjectConstructor.cpp:
731         (JSC::objectConstructorFreeze):
732         * runtime/ObjectConstructor.h:
733         * runtime/TemplateRegistry.cpp: Added.
734         (JSC::TemplateRegistry::TemplateRegistry):
735         (JSC::TemplateRegistry::getTemplateObject):
736         * runtime/TemplateRegistry.h: Added.
737         * runtime/TemplateRegistryKey.h: Added.
738         (JSC::TemplateRegistryKey::isDeletedValue):
739         (JSC::TemplateRegistryKey::isEmptyValue):
740         (JSC::TemplateRegistryKey::hash):
741         (JSC::TemplateRegistryKey::rawStrings):
742         (JSC::TemplateRegistryKey::cookedStrings):
743         (JSC::TemplateRegistryKey::operator==):
744         (JSC::TemplateRegistryKey::operator!=):
745         (JSC::TemplateRegistryKey::Hasher::hash):
746         (JSC::TemplateRegistryKey::Hasher::equal):
747         (JSC::TemplateRegistryKey::TemplateRegistryKey):
748         * runtime/VM.cpp:
749         (JSC::VM::VM):
750         * runtime/VM.h:
751         * tests/stress/tagged-templates-identity.js: Added.
752         (shouldBe):
753         * tests/stress/tagged-templates-raw-strings.js: Added.
754         (shouldBe):
755         (tag):
756         (testEval):
757         * tests/stress/tagged-templates-syntax.js: Added.
758         (tag):
759         (testSyntax):
760         (testSyntaxError):
761         * tests/stress/tagged-templates-template-object.js: Added.
762         (shouldBe):
763         (tag):
764         * tests/stress/tagged-templates-this.js: Added.
765         (shouldBe):
766         (tag):
767         * tests/stress/tagged-templates.js: Added.
768         (shouldBe):
769         (raw):
770         (cooked):
771         (Counter):
772
773 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
774
775         REGRESSION(r180595): same-callee profiling no longer works
776         https://bugs.webkit.org/show_bug.cgi?id=144787
777
778         Reviewed by Filip Pizlo.
779
780         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
781         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
782         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
783
784         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
785         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
786         our speculation that the callee is the same. To avoid recompiling the same code for different callee
787         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
788         LLint and baseline JIT when multiple callees are observed.
789
790         Tests: stress/create-this-with-callee-variants.js
791
792         * bytecode/BytecodeList.json: Increased the number of operands to 5.
793         * bytecode/CodeBlock.cpp:
794         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
795         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
796         * bytecompiler/BytecodeGenerator.cpp:
797         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
798         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
799         operand.
800         * dfg/DFGByteCodeParser.cpp:
801         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
802         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
803         * jit/JITOpcodes.cpp:
804         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
805         as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
806         (JSC::JIT::emitSlow_op_create_this):
807         * jit/JITOpcodes32_64.cpp:
808         (JSC::JIT::emit_op_create_this): Ditto.
809         (JSC::JIT::emitSlow_op_create_this):
810         * llint/LowLevelInterpreter32_64.asm:
811         (_llint_op_create_this): Ditto.
812         * llint/LowLevelInterpreter64.asm:
813         (_llint_op_create_this): Ditto.
814         * runtime/CommonSlowPaths.cpp:
815         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
816         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
817         * runtime/JSCell.h:
818         (JSC::JSCell::seenMultipleCalleeObjects): Added.
819         * runtime/WriteBarrier.h:
820         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
821         * tests/stress/create-this-with-callee-variants.js: Added.
822
823 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
824
825         Clean up some possible RefPtr to PassRefPtr churn
826         https://bugs.webkit.org/show_bug.cgi?id=144779
827
828         Reviewed by Darin Adler.
829
830         * runtime/GenericTypedArrayViewInlines.h:
831         (JSC::GenericTypedArrayView<Adaptor>::create):
832         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
833         * runtime/JSArrayBufferConstructor.cpp:
834         (JSC::constructArrayBuffer):
835         * runtime/Structure.cpp:
836         (JSC::Structure::toStructureShape):
837         * runtime/TypedArrayBase.h:
838         (JSC::TypedArrayBase::create):
839         (JSC::TypedArrayBase::createUninitialized):
840         * tools/FunctionOverrides.cpp:
841         (JSC::initializeOverrideInfo):
842         Release the last use of a RefPtr as it is passed on.
843
844 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
845
846         ES6: Allow duplicate property names
847         https://bugs.webkit.org/show_bug.cgi?id=142895
848
849         Reviewed by Geoffrey Garen.
850
851         Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
852         that will define a single getter or setter property on an object.
853
854         The existing `op_put_getter_setter` opcode is still preferred for
855         putting both a getter and setter at the same time but cannot be used
856         for putting an individual getter or setter which is needed in
857         some cases.
858
859         Add a new slow path when generating bytecodes for a property list
860         with computed properties, as computed properties are the only time
861         the list of properties cannot be determined statically.
862
863         * bytecompiler/NodesCodegen.cpp:
864         (JSC::PropertyListNode::emitBytecode):
865         - fast path for all constant properties
866         - slow but paired getter/setter path if there are no computed properties
867         - slow path, individual put operation for every property, if there are computed properties
868
869         * parser/Nodes.h:
870         Distinguish a Computed property from a Constant property.
871
872         * parser/Parser.cpp:
873         (JSC::Parser<LexerType>::parseProperty):
874         (JSC::Parser<LexerType>::parsePropertyMethod):
875         Distingish Computed and Constant properties.
876
877         (JSC::Parser<LexerType>::parseObjectLiteral):
878         When we drop into strict mode it is because we saw a getter
879         or setter, so be more explicit.
880
881         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
882         Eliminate duplicate property syntax error exception.
883
884         * parser/SyntaxChecker.h:
885         (JSC::SyntaxChecker::getName):
886         * parser/ASTBuilder.h:
887         (JSC::ASTBuilder::getName): Deleted.
888         No longer used.
889
890         * runtime/JSObject.h:
891         (JSC::JSObject::putDirectInternal):
892         When updating a property. If the Accessor attribute changed
893         update the Structure.
894
895         * runtime/JSObject.cpp:
896         (JSC::JSObject::putGetter):
897         (JSC::JSObject::putSetter):
898         Called by the opcodes, just perform the same operation that
899         __defineGetter__ or __defineSetter__ would do.
900
901         (JSC::JSObject::putDirectNonIndexAccessor):
902         This transition is now handled in putDirectInternal.
903
904         * runtime/Structure.h:
905         Add needed export.
906
907         * bytecode/BytecodeList.json:
908         * bytecode/BytecodeUseDef.h:
909         (JSC::computeUsesForBytecodeOffset):
910         (JSC::computeDefsForBytecodeOffset):
911         * bytecode/CodeBlock.cpp:
912         (JSC::CodeBlock::dumpBytecode):
913         * bytecompiler/BytecodeGenerator.cpp:
914         (JSC::BytecodeGenerator::emitPutGetterById):
915         (JSC::BytecodeGenerator::emitPutSetterById):
916         * bytecompiler/BytecodeGenerator.h:
917         * jit/JIT.cpp:
918         (JSC::JIT::privateCompileMainPass):
919         * jit/JIT.h:
920         * jit/JITInlines.h:
921         (JSC::JIT::callOperation):
922         * jit/JITOperations.cpp:
923         * jit/JITOperations.h:
924         * jit/JITPropertyAccess.cpp:
925         (JSC::JIT::emit_op_put_getter_by_id):
926         (JSC::JIT::emit_op_put_setter_by_id):
927         * jit/JITPropertyAccess32_64.cpp:
928         (JSC::JIT::emit_op_put_getter_by_id):
929         (JSC::JIT::emit_op_put_setter_by_id):
930         * llint/LLIntSlowPaths.cpp:
931         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
932         * llint/LLIntSlowPaths.h:
933         * llint/LowLevelInterpreter.asm:
934         New bytecodes. Modelled after existing op_put_getter_setter.
935
936 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
937
938         Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
939         https://bugs.webkit.org/show_bug.cgi?id=144856
940
941         Reviewed by Benjamin Poulain.
942         
943         First I made fixTypeForRepresentation() print out better diagnostics when it dies.
944         
945         Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
946         converts to a representation-changing node, it needs to use one of the UseKinds that such
947         a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
948         something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
949
950         * dfg/DFGAbstractInterpreter.h:
951         (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
952         * dfg/DFGAbstractInterpreterInlines.h:
953         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
954         * dfg/DFGAbstractValue.cpp:
955         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
956         * dfg/DFGAbstractValue.h:
957         * dfg/DFGInPlaceAbstractState.cpp:
958         (JSC::DFG::InPlaceAbstractState::initialize):
959         * dfg/DFGNode.cpp:
960         (JSC::DFG::Node::convertToIdentityOn):
961         * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
962         (foo):
963
964 2015-05-13  Commit Queue  <commit-queue@webkit.org>
965
966         Unreviewed, rolling out r184313.
967         https://bugs.webkit.org/show_bug.cgi?id=144974
968
969         Introduced an assertion failure in class-syntax-
970         declaration.js, class-syntax-expression.js, and object-
971         literal-syntax.js (Requested by rniwa on #webkit).
972
973         Reverted changeset:
974
975         "Small refactoring before ES6 Arrow function implementation."
976         https://bugs.webkit.org/show_bug.cgi?id=144954
977         http://trac.webkit.org/changeset/184313
978
979 2015-05-13  Oliver Hunt  <oliver@apple.com>
980         Ensure that all the smart pointer types in WTF clear their pointer before deref
981         https://bugs.webkit.org/show_bug.cgi?id=143789
982
983         Reviewed by Ryosuke Niwa.
984
985         One of the simpler cases of this in JavaScriptCore. There
986         are other cases where we need to guard the derefs but they
987         are more complex cases.
988
989         * inspector/JSInjectedScriptHost.cpp:
990         (Inspector::JSInjectedScriptHost::releaseImpl):
991         * inspector/JSJavaScriptCallFrame.cpp:
992         (Inspector::JSJavaScriptCallFrame::releaseImpl):
993
994 2015-05-13  Alexandr Skachkov  <gskachkov@gmail.com>
995
996         Small refactoring before ES6 Arrow function implementation.
997         https://bugs.webkit.org/show_bug.cgi?id=144954
998
999         Reviewed by Filip Pizlo.
1000
1001         * parser/Parser.h:
1002         * parser/Parser.cpp:
1003
1004 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
1005
1006         The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
1007         https://bugs.webkit.org/show_bug.cgi?id=144945
1008
1009         Reviewed by Michael Saboff.
1010         
1011         We were making the mistake of using DFG liveness for object allocation sinking decisions.
1012         This is wrong. In fact we almost never want to use DFG liveness directly. The only place
1013         where that makes sense is pruning in DFG AI.
1014         
1015         So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
1016         liveness.
1017         
1018         In the process of doing this, I realized that the DFGForAllKills definition of combined
1019         liveness at block tail was not strictly right; it was using the bytecode liveness at the
1020         block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
1021         I changed DFGForAllKills to work in terms of CombinedLiveness.
1022         
1023         This allows me to unskip the test I added in r184260. I also added a new test that tries to
1024         trigger this bug more directly.
1025
1026         * CMakeLists.txt:
1027         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1028         * JavaScriptCore.xcodeproj/project.pbxproj:
1029         * dfg/DFGArgumentsEliminationPhase.cpp:
1030         * dfg/DFGCombinedLiveness.cpp: Added.
1031         (JSC::DFG::liveNodesAtHead):
1032         (JSC::DFG::CombinedLiveness::CombinedLiveness):
1033         * dfg/DFGCombinedLiveness.h: Added.
1034         (JSC::DFG::CombinedLiveness::CombinedLiveness):
1035         * dfg/DFGForAllKills.h:
1036         (JSC::DFG::forAllKillsInBlock):
1037         (JSC::DFG::forAllLiveNodesAtTail): Deleted.
1038         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1039         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
1040         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
1041         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
1042         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
1043         * tests/stress/escape-object-in-diamond-then-exit.js: Added.
1044         * tests/stress/sink-object-past-invalid-check-sneaky.js:
1045
1046 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
1047
1048         I skipped a wrong test in r184270. Fix that.
1049         The failure is tracked by webkit.org/b/144947.
1050
1051         * tests/stress/arith-modulo-node-behaviors.js:
1052         * tests/stress/arith-mul-with-constants.js:
1053
1054 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1055
1056         Avoid always running some debug code in type profiling
1057         https://bugs.webkit.org/show_bug.cgi?id=144775
1058
1059         Reviewed by Daniel Bates.
1060
1061         * runtime/TypeProfilerLog.cpp:
1062         (JSC::TypeProfilerLog::processLogEntries):
1063
1064 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
1065
1066         Pass String as reference in more places
1067         https://bugs.webkit.org/show_bug.cgi?id=144769
1068
1069         Reviewed by Daniel Bates.
1070
1071         * debugger/Breakpoint.h:
1072         (JSC::Breakpoint::Breakpoint):
1073         * parser/Parser.h:
1074         (JSC::Parser::setErrorMessage):
1075         (JSC::Parser::updateErrorWithNameAndMessage):
1076         * parser/ParserError.h:
1077         (JSC::ParserError::ParserError):
1078         * runtime/RegExp.cpp:
1079         (JSC::RegExpFunctionalTestCollector::outputOneTest):
1080         * runtime/RegExpObject.cpp:
1081         (JSC::regExpObjectSourceInternal):
1082         * runtime/TypeProfiler.cpp:
1083         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
1084         * runtime/TypeProfilerLog.cpp:
1085         (JSC::TypeProfilerLog::processLogEntries):
1086         * runtime/TypeProfilerLog.h:
1087         * tools/FunctionOverrides.cpp:
1088         (JSC::initializeOverrideInfo):
1089         * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
1090         (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
1091
1092         * inspector/scripts/codegen/objc_generator_templates.py:
1093         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
1094         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1095         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
1096         * inspector/scripts/tests/expected/enum-values.json-result:
1097         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
1098         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
1099         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
1100         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
1101         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
1102         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
1103         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
1104         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
1105         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
1106         Rebaseline tests after updating the generator.
1107
1108 2015-05-13  Michael Saboff  <msaboff@apple.com>
1109
1110         com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
1111         https://bugs.webkit.org/show_bug.cgi?id=144933
1112
1113         Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT.  Added some diagnostic messages to
1114         help determine the cause for any crash.
1115
1116         Reviewed by Geoffrey Garen.
1117
1118         * bytecode/CodeBlock.cpp:
1119         (JSC::CodeBlock::finalizeUnconditionally):
1120
1121 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
1122
1123         REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
1124         https://bugs.webkit.org/show_bug.cgi?id=144951
1125
1126         Reviewed by Michael Saboff.
1127         
1128         There were two issues here:
1129         
1130         - In r184260 we expected a small number of possible use kinds in Check nodes, and
1131           UntypedUse was not one of them. That seemed like a sensible assumption because we don't
1132           create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
1133           Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
1134           follow the same idiom as everyone else and not create tautological checks.
1135         
1136         - It's clearly not very robust to assume that Checks will not be used tautologically. So,
1137           this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
1138           which catches cases that AI would have already marked as unnecessary. It then also uses
1139           a new helper called alreadyChecked(), which allows us to just ask if the check is
1140           unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
1141
1142         * dfg/DFGArgumentsEliminationPhase.cpp:
1143         * dfg/DFGMayExit.cpp:
1144         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1145         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1146         * dfg/DFGSSAConversionPhase.cpp:
1147         (JSC::DFG::SSAConversionPhase::run):
1148         * dfg/DFGUseKind.h:
1149         (JSC::DFG::alreadyChecked):
1150         * dfg/DFGVarargsForwardingPhase.cpp:
1151
1152 k
1153 2015-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1154
1155         [ES6] Implement String.raw
1156         https://bugs.webkit.org/show_bug.cgi?id=144330
1157
1158         Reviewed by Filip Pizlo.
1159
1160         Implement String.raw. It is intended to be used with tagged-templates syntax.
1161         To implement ToString abstract operation efficiently,
1162         we introduce @toString bytecode intrinsic. It emits op_to_string directly.
1163
1164         * CMakeLists.txt:
1165         * builtins/StringConstructor.js: Added.
1166         (raw):
1167         * bytecompiler/NodesCodegen.cpp:
1168         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
1169         * runtime/CommonIdentifiers.h:
1170         * runtime/StringConstructor.cpp:
1171         * tests/stress/string-raw.js: Added.
1172         (shouldBe):
1173         (.get shouldBe):
1174         (Counter):
1175
1176 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
1177
1178         Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
1179
1180         * tests/stress/arith-mul-with-constants.js:
1181
1182 2015-05-12  Filip Pizlo  <fpizlo@apple.com>
1183
1184         js/dom/stack-trace.html fails with eager compilation
1185         https://bugs.webkit.org/show_bug.cgi?id=144853
1186
1187         Reviewed by Benjamin Poulain.
1188         
1189         All of our escape analyses were mishandling Check(). They were assuming that this is a
1190         non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
1191         candidate, then we need to do something: if we eliminate or sink @x, then the check no
1192         longer makes any sense since a phantom allocation has no type. This will make us forget
1193         that this operation would have exited. This was causing us to not call a valueOf method in
1194         js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
1195         +o where o had a valueOf method, and o was otherwise sinkable.
1196         
1197         This changes our escape analyses to basically pretend that any Check() that isn't obviously
1198         unnecessary is an escape. We don't have to be super careful here. Most checks will be
1199         completely eliminated by constant-folding. If that doesn't run in time, then the most
1200         common check we will see is CellUse. So, we just recognize some very obvious check kinds
1201         that we know would have passed, and for all of the rest we just assume that it's an escape.
1202         
1203         This was super tricky to test. The obvious way to test it is to use +o like
1204         stack-trace.html, except that doing so relies on the fact that we still haven't implemented
1205         the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
1206         
1207         1) Use +o. These will test what we want it to test for now, but at some point in the future
1208            these tests will just be a good sanity-check that our op_to_number implementation is
1209            right.
1210         
1211         2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
1212            operation always sees integers even though we eventually feed it an object and that
1213            object is a sink candidate.
1214         
1215         3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
1216            value is an int32. This intrinsic is required to be implemented by DFG by
1217            unconditionally speculating that the input is int32. This allows us to write much more
1218            targetted tests of the underlying issue.
1219         
1220         4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
1221            get regression test coverage of this test in eager mode.
1222
1223         * dfg/DFGArgumentsEliminationPhase.cpp:
1224         * dfg/DFGByteCodeParser.cpp:
1225         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1226         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1227         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
1228         * dfg/DFGVarargsForwardingPhase.cpp:
1229         * ftl/FTLExitValue.cpp:
1230         (JSC::FTL::ExitValue::dumpInContext):
1231         * ftl/FTLLowerDFGToLLVM.cpp:
1232         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1233         * ftl/FTLOSRExitCompiler.cpp:
1234         (JSC::FTL::compileFTLOSRExit):
1235         * jsc.cpp:
1236         (GlobalObject::finishCreation):
1237         (functionIsInt32):
1238         * runtime/Intrinsic.h:
1239         * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
1240         * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
1241         * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
1242         * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
1243         * tests/stress/sink-arguments-past-invalid-check.js: Added.
1244         * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
1245         * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
1246         * tests/stress/sink-object-past-invalid-check-int32.js: Added.
1247         * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
1248         * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
1249         * tests/stress/sink-object-past-invalid-check.js: Added.
1250
1251 2015-05-12  Benjamin Poulain  <benjamin@webkit.org>
1252
1253         Fix the iteration count of arith-modulo-node-behaviors.js
1254
1255         * tests/stress/arith-modulo-node-behaviors.js:
1256         No need for big numbers for the real testing.
1257
1258 2015-05-12  Mark Lam  <mark.lam@apple.com>
1259
1260         Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
1261         https://bugs.webkit.org/show_bug.cgi?id=144924
1262
1263         Reviewed by Alex Christensen.
1264
1265         The present stack scanning code in the Windows port is expecting that the
1266         GetCurrentThread() API will provide a unique HANDLE for each thread.  The code
1267         then saves and later uses that HANDLE with GetThreadContext() to get the
1268         runtime state of the target thread from the GC thread.  According to
1269         https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
1270         GetCurrentThread() does not provide this unique HANDLE that we expect:
1271
1272             "The function cannot be used by one thread to create a handle that can
1273             be used by other threads to refer to the first thread. The handle is
1274             always interpreted as referring to the thread that is using it. A
1275             thread can create a "real" handle to itself that can be used by other
1276             threads, or inherited by other processes, by specifying the pseudo
1277             handle as the source handle in a call to the DuplicateHandle function."
1278
1279         As a result of this, GetCurrentThread() always returns the same HANDLE value, and
1280         we end up never scanning the stacks of other threads because we wrongly think that
1281         they are all equal (in identity) to the scanning thread.  This, in turn, results
1282         in crashes due to objects that are incorrectly collected.
1283
1284         The fix is to call DuplicateHandle() to create a HANDLE that we can use.  The
1285         MachineThreads::Thread class already accurately tracks the period of time when
1286         we need that HANDLE for the VM.  Hence, the life-cycle of the HANDLE can be tied
1287         to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
1288
1289         * heap/MachineStackMarker.cpp:
1290         (JSC::getCurrentPlatformThread):
1291         (JSC::MachineThreads::Thread::Thread):
1292         (JSC::MachineThreads::Thread::~Thread):
1293         (JSC::MachineThreads::Thread::suspend):
1294         (JSC::MachineThreads::Thread::resume):
1295         (JSC::MachineThreads::Thread::getRegisters):
1296
1297 2015-05-12  Benjamin Poulain  <bpoulain@apple.com>
1298
1299         [JSC] Make the NegZero backward propagated flags of ArithMod stricter
1300         https://bugs.webkit.org/show_bug.cgi?id=144897
1301
1302         Reviewed by Geoffrey Garen.
1303
1304         The NegZero flags of ArithMod were the same as ArithDiv: both children were
1305         marked as needing to handle NegativeZero.
1306
1307         Lucky for us, ArithMod is quite a bit different than ArithDiv.
1308
1309         First, the sign of the result is completely independent from
1310         the sign of the divisor. A zero on the divisor always produces a NaN.
1311         That's great, we can remove the NodeBytecodeNeedsNegZero
1312         from the flags propagated to child2.
1313
1314         Second, the sign of the result is always the same as the sign of
1315         the dividend. A dividend of zero produces a zero of same sign
1316         unless the divisor is zero (in which case the result is NaN).
1317         This is great too: we can just pass the flags we got into
1318         ArithMod.
1319
1320         With those two out of the way, we can make a faster version of ArithRound
1321         for Kraken's oscillator. Since we no longer care about negative zero,
1322         rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
1323         on the benchmark.
1324
1325         Unfortunatelly, most of the time is spent in FTL and the same optimization
1326         does not apply well just yet: rdar://problem/20904149.
1327
1328         * dfg/DFGBackwardsPropagationPhase.cpp:
1329         (JSC::DFG::BackwardsPropagationPhase::propagate):
1330         Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
1331
1332         * dfg/DFGSpeculativeJIT.cpp:
1333         (JSC::DFG::SpeculativeJIT::compileArithRound):
1334         Faster Math.round() when negative zero is not important.
1335
1336         * tests/stress/arith-modulo-node-behaviors.js: Added.
1337         (moduloWithNegativeZeroDividend):
1338         (moduloWithUnusedNegativeZeroDividend):
1339         (moduloWithNegativeZeroDivisor):
1340
1341 2015-05-12  Mark Lam  <mark.lam@apple.com>
1342
1343         Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
1344         https://bugs.webkit.org/show_bug.cgi?id=144925
1345
1346         Reviewed by Michael Saboff.
1347
1348         Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
1349         operate on the platformThread value in the MachineThreads::Thread struct.  Instead, we
1350         can apply better OO encapsulation and convert all these functions into methods of the
1351         MachineThreads::Thread struct.
1352
1353         This will also make it easier to reason about the fix for
1354         https://bugs.webkit.org/show_bug.cgi?id=144924 later.
1355
1356         * heap/MachineStackMarker.cpp:
1357         (JSC::getCurrentPlatformThread):
1358         (JSC::MachineThreads::Thread::createForCurrentThread):
1359         (JSC::MachineThreads::Thread::operator!=):
1360         (JSC::MachineThreads::Thread::operator==):
1361         (JSC::MachineThreads::addCurrentThread):
1362         (JSC::MachineThreads::removeThreadIfFound):
1363         (JSC::MachineThreads::Thread::suspend):
1364         (JSC::MachineThreads::Thread::resume):
1365         (JSC::MachineThreads::Thread::getRegisters):
1366         (JSC::MachineThreads::Thread::Registers::stackPointer):
1367         (JSC::MachineThreads::Thread::freeRegisters):
1368         (JSC::MachineThreads::Thread::captureStack):
1369         (JSC::MachineThreads::tryCopyOtherThreadStack):
1370         (JSC::MachineThreads::tryCopyOtherThreadStacks):
1371         (JSC::equalThread): Deleted.
1372         (JSC::suspendThread): Deleted.
1373         (JSC::resumeThread): Deleted.
1374         (JSC::getPlatformThreadRegisters): Deleted.
1375         (JSC::otherThreadStackPointer): Deleted.
1376         (JSC::freePlatformThreadRegisters): Deleted.
1377         (JSC::otherThreadStack): Deleted.
1378
1379 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
1380
1381         Array.slice should have a fast path like Array.splice
1382         https://bugs.webkit.org/show_bug.cgi?id=144901
1383
1384         Reviewed by Geoffrey Garen.
1385
1386         Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
1387         In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
1388
1389         * runtime/ArrayPrototype.cpp:
1390         (JSC::arrayProtoFuncSlice):
1391         * runtime/JSArray.cpp:
1392         (JSC::JSArray::fastSlice): Added.
1393         * runtime/JSArray.h:
1394
1395 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1396
1397         OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
1398         https://bugs.webkit.org/show_bug.cgi?id=143078
1399
1400         Reviewed by Andreas Kling.
1401         
1402         In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
1403         pruning is actually necessary. Well, not quite: we just need to prune out keys from the
1404         heap availability map where the base node doesn't dominate the point where we are asking
1405         for availability. If we don't do this, then eventually the IR gets corrupt because we'll
1406         insert PutHints that reference the base node in places where the base node doesn't
1407         dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
1408         liveness. This is the strongest possible pruning we can do, and it should be sound. We
1409         shouldn't have a node available for a virtual register if that register is live and the
1410         node doesn't dominate.
1411         
1412         Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
1413         abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
1414
1415         * dfg/DFGAvailabilityMap.cpp:
1416         (JSC::DFG::AvailabilityMap::pruneHeap):
1417         (JSC::DFG::AvailabilityMap::pruneByLiveness):
1418         (JSC::DFG::AvailabilityMap::prune): Deleted.
1419         * dfg/DFGAvailabilityMap.h:
1420         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1421         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
1422         * ftl/FTLLowerDFGToLLVM.cpp:
1423         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1424         * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
1425         * 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.
1426
1427 2015-05-12  Gabor Loki  <loki@webkit.org>
1428
1429         Workaround for Cortex-A53 erratum 843419
1430         https://bugs.webkit.org/show_bug.cgi?id=144680
1431
1432         Reviewed by Michael Saboff.
1433
1434         This patch is about to give simple workaround for Cortex-A53 erratum 843419.
1435         It inserts nops after ADRP instruction to avoid wrong address accesses.
1436
1437         * assembler/ARM64Assembler.h:
1438         (JSC::ARM64Assembler::adrp):
1439         (JSC::ARM64Assembler::nopCortexA53Fix843419):
1440
1441 2015-05-11  Commit Queue  <commit-queue@webkit.org>
1442
1443         Unreviewed, rolling out r184009.
1444         https://bugs.webkit.org/show_bug.cgi?id=144900
1445
1446         Caused crashes on inspector tests (Requested by ap on
1447         #webkit).
1448
1449         Reverted changeset:
1450
1451         "MapDataImpl::add() shouldn't do the same hash lookup twice."
1452         https://bugs.webkit.org/show_bug.cgi?id=144759
1453         http://trac.webkit.org/changeset/184009
1454
1455 2015-05-11  Commit Queue  <commit-queue@webkit.org>
1456
1457         Unreviewed, rolling out r184123.
1458         https://bugs.webkit.org/show_bug.cgi?id=144899
1459
1460         Seems to have introduced flaky crashes in many JS tests
1461         (Requested by rniwa on #webkit).
1462
1463         Reverted changeset:
1464
1465         "REGRESSION(r180595): same-callee profiling no longer works"
1466         https://bugs.webkit.org/show_bug.cgi?id=144787
1467         http://trac.webkit.org/changeset/184123
1468
1469 2015-05-11  Brent Fulgham  <bfulgham@apple.com>
1470
1471         [Win] Move Windows build target to Windows 7 (or newer)
1472         https://bugs.webkit.org/show_bug.cgi?id=144890
1473         <rdar://problem/20707307>
1474
1475         Reviewed by Anders Carlsson.
1476
1477         Update linked SDK and minimal Windows level to be compatible with
1478         Windows 7 or newer.
1479
1480         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1481         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1482         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
1483         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
1484         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
1485         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
1486         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
1487         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
1488         * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
1489         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
1490         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
1491         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
1492         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
1493         * config.h:
1494
1495 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1496
1497         CPS rethreading phase's flush detector flushes way too many SetLocals
1498         https://bugs.webkit.org/show_bug.cgi?id=144819
1499
1500         Reviewed by Geoffrey Garen.
1501         
1502         After probably unrelated changes, this eventually caused some arguments elimination to stop
1503         working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
1504         a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
1505         meant to only affect the SetLocal itself.
1506         
1507         This is a speed-up on Octane/earley.
1508
1509         * dfg/DFGCPSRethreadingPhase.cpp:
1510         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
1511
1512 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1513
1514         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.
1515         https://bugs.webkit.org/show_bug.cgi?id=144854
1516
1517         Reviewed by Oliver Hunt.
1518         
1519         This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
1520         It used to be that Construct required less code, but that's not the case for now.
1521
1522         * ftl/FTLInlineCacheSize.cpp:
1523         (JSC::FTL::sizeOfCallForwardVarargs):
1524         (JSC::FTL::sizeOfConstructVarargs):
1525         (JSC::FTL::sizeOfConstructForwardVarargs):
1526
1527 2015-05-11  Ryosuke Niwa  <rniwa@webkit.org>
1528
1529         REGRESSION(r180595): same-callee profiling no longer works
1530         https://bugs.webkit.org/show_bug.cgi?id=144787
1531
1532         Reviewed by Michael Saboff.
1533
1534         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
1535         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
1536         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
1537
1538         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
1539         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
1540         our speculation that the callee is the same. To avoid recompiling the same code for different callee
1541         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
1542         LLint and baseline JIT when multiple callees are observed.
1543
1544         Tests: stress/create-this-with-callee-variants.js
1545
1546         * bytecode/BytecodeList.json: Increased the number of operands to 5.
1547         * bytecode/BytecodeUseDef.h:
1548         (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
1549         operands.
1550         * bytecode/CodeBlock.cpp:
1551         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
1552         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
1553         * bytecompiler/BytecodeGenerator.cpp:
1554         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
1555         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
1556         operand.
1557         * dfg/DFGByteCodeParser.cpp:
1558         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
1559         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
1560         * jit/JITOpcodes.cpp:
1561         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
1562         as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
1563         (JSC::JIT::emitSlow_op_create_this):
1564         * jit/JITOpcodes32_64.cpp:
1565         (JSC::JIT::emit_op_create_this): Ditto.
1566         (JSC::JIT::emitSlow_op_create_this):
1567         * llint/LowLevelInterpreter32_64.asm:
1568         (_llint_op_create_this): Ditto.
1569         * llint/LowLevelInterpreter64.asm:
1570         (_llint_op_create_this): Ditto.
1571         * runtime/CommonSlowPaths.cpp:
1572         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
1573         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
1574         * runtime/JSCell.h:
1575         (JSC::JSCell::seenMultipleCalleeObjects): Added.
1576         * runtime/WriteBarrier.h:
1577         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
1578         * tests/stress/create-this-with-callee-variants.js: Added.
1579
1580 2015-05-11  Andreas Kling  <akling@apple.com>
1581
1582         PropertyNameArray should use a Vector when there are few entries.
1583         <https://webkit.org/b/144874>
1584
1585         Reviewed by Geoffrey Garen.
1586
1587         Bring back an optimization that was lost in the for-in refactoring.
1588         PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
1589         enough (20) entries to justify converting to a HashSet for contains().
1590
1591         Also inlined the code while we're here, since it has so few clients and
1592         the call overhead adds up.
1593
1594         ~5% progression on Kraken/json-stringify-tinderbox.
1595
1596         * runtime/PropertyNameArray.cpp: Removed.
1597         * runtime/PropertyNameArray.h:
1598         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1599         (JSC::PropertyNameArray::add):
1600         (JSC::PropertyNameArray::addKnownUnique):
1601
1602 2015-05-11  Matt Baker  <mattbaker@apple.com>
1603
1604         Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
1605         https://bugs.webkit.org/show_bug.cgi?id=144808
1606
1607         Reviewed by Darin Adler.
1608
1609         Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
1610         The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
1611
1612         * profiler/Profile.cpp:
1613         (JSC::Profile::create):
1614         (JSC::Profile::Profile):
1615         * profiler/Profile.h:
1616         * profiler/ProfileGenerator.cpp:
1617         (JSC::ProfileGenerator::ProfileGenerator):
1618         (JSC::AddParentForConsoleStartFunctor::operator()):
1619
1620 2015-05-11  Basile Clement  <basile_clement@apple.com>
1621
1622         Unreviewed, remove unintended change.
1623
1624         * dfg/DFGAbstractInterpreterInlines.h:
1625         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1626
1627 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1628
1629         Make it easy to enable eager/non-concurrent JIT compilation
1630         https://bugs.webkit.org/show_bug.cgi?id=144877
1631
1632         Reviewed by Michael Saboff.
1633
1634         * runtime/Options.cpp:
1635         (JSC::recomputeDependentOptions):
1636         * runtime/Options.h:
1637
1638 2015-05-10  Filip Pizlo  <fpizlo@apple.com>
1639
1640         We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
1641         https://bugs.webkit.org/show_bug.cgi?id=144851
1642
1643         Reviewed by Michael Saboff.
1644         
1645         LoadVarargs loads arguments from some object and puts them on the stack. The region of
1646         stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
1647         shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
1648         something that uses more stack than the LoadVarargs wanted to.
1649         
1650         This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
1651         promoter. This is an important promotion rule for performance, and in cases where we are
1652         compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
1653         the phantom arguments array that this phase sees. The LoadVarargs limit is based on
1654         profiling and the phantom arguments array is a proof; in most cases the profiling is more
1655         conservative.
1656         
1657         But, you could write some crazy code where the statically obvious arguments array value is
1658         bigger than what the profiling would have told you. When this happens, this promotion
1659         effectively removes a bounds check. This either results in us clobbering a bunch of stack,
1660         or it means that we never initialize a region of the stack that a later operation will read
1661         (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
1662         unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
1663         the original LoadVarargs limit).
1664         
1665         * dfg/DFGArgumentsEliminationPhase.cpp:
1666         * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
1667         (foo):
1668         (bar):
1669         (baz):
1670         * tests/stress/load-varargs-elimination-bounds-check.js: Added.
1671         (foo):
1672         (bar):
1673         (baz):
1674
1675 2015-05-11  Andreas Kling  <akling@apple.com>
1676
1677         JSON.stringify shouldn't use generic get() to access Array.length
1678         <https://webkit.org/b/144847>
1679
1680         Reviewed by Geoffrey Garen.
1681
1682         If the value being serialized is a JSArray object, we can downcast and call its
1683         length() directly instead of doing a generic property lookup.
1684
1685         0.5% progression on Kraken/json-stringify-tinderbox.
1686
1687         * runtime/JSONObject.cpp:
1688         (JSC::Stringifier::Holder::appendNextProperty):
1689
1690 2015-05-10  Andreas Kling  <akling@apple.com>
1691
1692         Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
1693
1694         Follow up to r184050 suggested by Darin.
1695
1696         * runtime/PropertyNameArray.h:
1697
1698 2015-05-10  Andreas Kling  <akling@apple.com>
1699
1700         Remove unused things from PropertyNameArray.
1701         <https://webkit.org/b/144834>
1702
1703         Reviewed by Filip Pizlo.
1704
1705         PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
1706         was refactored and optimized last year. Then more refactoring happened and this class
1707         doesn't need to ring and toot anymore.
1708
1709         The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
1710         actually using it for anything and we were just wasting time creating these.
1711
1712         Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
1713
1714         * runtime/JSObject.cpp:
1715         (JSC::JSObject::getPropertyNames):
1716         * runtime/JSPropertyNameEnumerator.cpp:
1717         (JSC::JSPropertyNameEnumerator::create):
1718         (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
1719         * runtime/JSPropertyNameEnumerator.h:
1720         * runtime/PropertyNameArray.cpp:
1721         (JSC::PropertyNameArray::add):
1722         (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
1723         * runtime/PropertyNameArray.h:
1724         (JSC::PropertyNameArray::PropertyNameArray):
1725         (JSC::PropertyNameArray::add):
1726         (JSC::PropertyNameArray::addKnownUnique):
1727         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1728         (JSC::RefCountedIdentifierSet::contains): Deleted.
1729         (JSC::RefCountedIdentifierSet::size): Deleted.
1730         (JSC::RefCountedIdentifierSet::add): Deleted.
1731         (JSC::PropertyNameArray::identifierSet): Deleted.
1732         (JSC::PropertyNameArray::numCacheableSlots): Deleted.
1733         (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
1734         (JSC::PropertyNameArray::setBaseObject): Deleted.
1735         (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
1736
1737 2015-05-09  Yoav Weiss  <yoav@yoav.ws>
1738
1739         Remove the PICTURE_SIZES build flag
1740         https://bugs.webkit.org/show_bug.cgi?id=144679
1741
1742         Reviewed by Benjamin Poulain.
1743
1744         Removed the PICTURE_SIZES build time flag.
1745
1746         * Configurations/FeatureDefines.xcconfig:
1747
1748 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1749
1750         Extend the SaneChain optimization to Contiguous arrays
1751         https://bugs.webkit.org/show_bug.cgi?id=144664
1752
1753         Reviewed by Mark Lam.
1754         
1755         Previously if you loaded from a hole, you'd either have to take slow path for the array
1756         load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
1757         gathered the necessary profiling yet). But that's unnecessary if we know that the
1758         prototype chain is sane - i.e. has no indexed properties. Then we can just return
1759         Undefined for the hole.
1760         
1761         Making this change requires setting more watchpoints on the array prototype chain. But
1762         that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
1763         itself up lazily. This means that this increased the number of recompilations we'd get
1764         due to the array prototype chain being built up.
1765         
1766         So, this change also removes the laziness and static tables from ArrayPrototype.
1767         
1768         But to make that change, I also had to add a helper for eagerly building up a prototype
1769         that has builtin functions.
1770
1771         * CMakeLists.txt:
1772         * DerivedSources.make:
1773         * dfg/DFGArrayMode.h:
1774         * dfg/DFGFixupPhase.cpp:
1775         (JSC::DFG::FixupPhase::fixupNode):
1776         * dfg/DFGSpeculativeJIT32_64.cpp:
1777         (JSC::DFG::SpeculativeJIT::compile):
1778         * dfg/DFGSpeculativeJIT64.cpp:
1779         (JSC::DFG::SpeculativeJIT::compile):
1780         * ftl/FTLLowerDFGToLLVM.cpp:
1781         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
1782         * runtime/ArrayPrototype.cpp:
1783         (JSC::ArrayPrototype::finishCreation):
1784         (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
1785         * runtime/ArrayPrototype.h:
1786         * runtime/JSObject.h:
1787
1788 2015-05-08  Michael Saboff  <msaboff@apple.com>
1789
1790         Creating a large MarkedBlock sometimes results in more than one cell in the block
1791         https://bugs.webkit.org/show_bug.cgi?id=144815
1792
1793         Reviewed by Mark Lam.
1794
1795         Large MarkedBlocks should have one and only one cell.  Changed the calculation of
1796         m_endAtom for large blocks to use the location of the first cell + 1.  This
1797         assures that large blocks only have one cell.
1798
1799         * heap/MarkedBlock.cpp:
1800         (JSC::MarkedBlock::MarkedBlock):
1801
1802 2015-05-08  Oliver Hunt  <oliver@apple.com>
1803
1804         MapDataImpl::add() shouldn't do the same hash lookup twice.
1805         https://bugs.webkit.org/show_bug.cgi?id=144759
1806
1807         Reviewed by Gavin Barraclough.
1808
1809         We don't actually need to do a double lookup here, all we need to
1810         do is update the index to point to the correct m_size.
1811
1812         * runtime/MapDataInlines.h:
1813         (JSC::JSIterator>::add):
1814
1815 2015-05-08  Andreas Kling  <akling@apple.com>
1816
1817         Micro-optimize JSON serialization of string primitives.
1818         <https://webkit.org/b/144800>
1819
1820         Reviewed by Sam Weinig.
1821
1822         Don't use the out-of-line JSValue::getString() to grab at string primitives
1823         in serialization. Just check if it's a JSString and then downcast to grab at
1824         the WTF::String inside.
1825
1826         2% progression on Kraken/json-stringify-tinderbox.
1827
1828         * runtime/JSONObject.cpp:
1829         (JSC::Stringifier::appendStringifiedValue):
1830
1831 2015-05-08  Andreas Kling  <akling@apple.com>
1832
1833         Optimize serialization of quoted JSON strings.
1834         <https://webkit.org/b/144754>
1835
1836         Reviewed by Darin Adler.
1837
1838         Optimized the serialization of quoted strings into JSON by moving the logic into
1839         StringBuilder so it can make smarter decisions about buffering.
1840
1841         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
1842
1843         * bytecompiler/NodesCodegen.cpp:
1844         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
1845
1846         * runtime/JSONObject.h:
1847         * runtime/JSONObject.cpp:
1848         (JSC::Stringifier::Holder::appendNextProperty):
1849         (JSC::appendStringToStringBuilder): Deleted.
1850         (JSC::appendQuotedJSONStringToBuilder): Deleted.
1851         (JSC::Stringifier::appendQuotedString): Deleted.
1852         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
1853         to StringBuilder and call that from here.
1854
1855 2015-05-07  Commit Queue  <commit-queue@webkit.org>
1856
1857         Unreviewed, rolling out r183961.
1858         https://bugs.webkit.org/show_bug.cgi?id=144784
1859
1860         Broke js/dom/JSON-stringify.html (Requested by kling on
1861         #webkit).
1862
1863         Reverted changeset:
1864
1865         "Optimize serialization of quoted JSON strings."
1866         https://bugs.webkit.org/show_bug.cgi?id=144754
1867         http://trac.webkit.org/changeset/183961
1868
1869 2015-05-07  Filip Pizlo  <fpizlo@apple.com>
1870
1871         GC has trouble with pathologically large array allocations
1872         https://bugs.webkit.org/show_bug.cgi?id=144609
1873
1874         Reviewed by Geoffrey Garen.
1875
1876         The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
1877         after pinning them), and would skip the accounting. The GC calculates the size of the heap
1878         in tandem with the scan to save time, and that accounting was part of how the GC would
1879         know how big the heap was. The GC would then think that oversize copied blocks use no
1880         memory, and would then mess up its scheduling of the next GC.
1881         
1882         Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
1883         size by summing the size from the last collection and the size by walking the eden heap.
1884         But this breaks when we eagerly delete objects that the last collection touched. We can do
1885         that in one corner case: copied block reallocation. The old block will be deleted from old
1886         space during the realloc and a new block will be allocated in new space. In order for the
1887         GC to know that the size of old space actually shrank, we need a field to tell us how much
1888         such shrinkage could occur. Since this is a very dirty corner case and it only works for
1889         very particular reasons arising from the special properties of copied space (single owner,
1890         and the realloc is used in places where the compiler already knows that it cannot register
1891         allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
1892         devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
1893         
1894         To test this, I needed to add an Option to force a particular RAM size in the GC. This
1895         allows us to write tests that assert that the GC heap size is some value X, without
1896         worrying about machine-to-machine variations due to GC heuristics changing based on RAM
1897         size.
1898
1899         * heap/CopiedSpace.cpp:
1900         (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
1901         (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
1902         * heap/CopiedSpace.h:
1903         (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
1904         * heap/Heap.cpp:
1905         (JSC::Heap::Heap): Allow the user to force the RAM size.
1906         (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
1907         * heap/SlotVisitorInlines.h:
1908         (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.
1909         * jsc.cpp: Add size measuring hooks to write the largeish test.
1910         (GlobalObject::finishCreation):
1911         (functionGCAndSweep):
1912         (functionFullGC):
1913         (functionEdenGC):
1914         (functionHeapSize):
1915         * runtime/Options.h:
1916         * 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.
1917         * 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.
1918         (foo):
1919         (test):
1920
1921 2015-05-07  Saam Barati  <saambarati1@gmail.com>
1922
1923         Global functions should be initialized as JSFunctions in byte code
1924         https://bugs.webkit.org/show_bug.cgi?id=144178
1925
1926         Reviewed by Geoffrey Garen.
1927
1928         This patch makes the initialization of global functions more explicit by
1929         moving initialization into bytecode. It also prepares JSC for having ES6
1930         style lexical scoping because initializing global functions in bytecode
1931         easily allows global functions to be initialized with the proper scope that
1932         will have access to global lexical variables. Global lexical variables
1933         should be visible to global functions but don't live on the global object.
1934
1935         * bytecode/UnlinkedCodeBlock.cpp:
1936         (JSC::UnlinkedProgramCodeBlock::visitChildren):
1937         * bytecode/UnlinkedCodeBlock.h:
1938         * bytecompiler/BytecodeGenerator.cpp:
1939         (JSC::BytecodeGenerator::generate):
1940         (JSC::BytecodeGenerator::BytecodeGenerator):
1941         * bytecompiler/BytecodeGenerator.h:
1942         * runtime/Executable.cpp:
1943         (JSC::ProgramExecutable::initializeGlobalProperties):
1944         * runtime/JSGlobalObject.cpp:
1945         (JSC::JSGlobalObject::addGlobalVar):
1946         (JSC::JSGlobalObject::addFunction):
1947         * runtime/JSGlobalObject.h:
1948
1949 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1950
1951         Fix the x86 32bits build
1952
1953         * assembler/X86Assembler.h:
1954
1955 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1956
1957         [JSC] Add basic DFG/FTL support for Math.round
1958         https://bugs.webkit.org/show_bug.cgi?id=144725
1959
1960         Reviewed by Filip Pizlo.
1961
1962         This patch adds two optimizations targeting Math.round():
1963         -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
1964         -Change the MacroAssembler to be stricter on how we fail to convert a double
1965          to ingeter. Previously, any number valued zero would fail, now we only
1966          fail for -0.
1967
1968         Since ArithRound speculate it produces int32, the MacroAssembler assembler
1969         part became necessary because zero is a pretty common output of Math.round()
1970         and we would OSR exit a lot (and eventually recompile for doubles).
1971
1972         The implementation itself of the inline Math.round() is exactly the same
1973         as the C function that exists for Math.round(). We can very likely do better
1974         but it is a good start known to be valid and inlining alone alread provides
1975         significant speedups.
1976
1977         * assembler/X86Assembler.h:
1978         (JSC::X86Assembler::movmskpd_rr):
1979         * assembler/MacroAssemblerX86Common.h:
1980         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
1981         When we have a zero, get the sign bit out of the double and check if is one.
1982
1983         I'll look into doing the same improvement for ARM.
1984
1985         * bytecode/SpeculatedType.cpp:
1986         (JSC::typeOfDoubleRounding):
1987         (JSC::typeOfDoubleFRound): Deleted.
1988         * bytecode/SpeculatedType.h:
1989         * dfg/DFGAbstractInterpreterInlines.h:
1990         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1991         * dfg/DFGByteCodeParser.cpp:
1992         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1993         * dfg/DFGClobberize.h:
1994         (JSC::DFG::clobberize):
1995         * dfg/DFGDoesGC.cpp:
1996         (JSC::DFG::doesGC):
1997         * dfg/DFGFixupPhase.cpp:
1998         (JSC::DFG::FixupPhase::fixupNode):
1999         * dfg/DFGGraph.h:
2000         (JSC::DFG::Graph::roundShouldSpeculateInt32):
2001         (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
2002         * dfg/DFGNode.h:
2003         (JSC::DFG::Node::arithNodeFlags):
2004         (JSC::DFG::Node::hasHeapPrediction):
2005         (JSC::DFG::Node::hasArithMode):
2006         * dfg/DFGNodeType.h:
2007         * dfg/DFGPredictionPropagationPhase.cpp:
2008         (JSC::DFG::PredictionPropagationPhase::propagate):
2009         * dfg/DFGSafeToExecute.h:
2010         (JSC::DFG::safeToExecute):
2011         * dfg/DFGSpeculativeJIT.cpp:
2012         (JSC::DFG::SpeculativeJIT::compileArithRound):
2013         * dfg/DFGSpeculativeJIT.h:
2014         * dfg/DFGSpeculativeJIT32_64.cpp:
2015         (JSC::DFG::SpeculativeJIT::compile):
2016         * dfg/DFGSpeculativeJIT64.cpp:
2017         (JSC::DFG::SpeculativeJIT::compile):
2018         * ftl/FTLCapabilities.cpp:
2019         (JSC::FTL::canCompile):
2020         * ftl/FTLIntrinsicRepository.h:
2021         * ftl/FTLLowerDFGToLLVM.cpp:
2022         (JSC::FTL::LowerDFGToLLVM::compileNode):
2023         (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
2024         (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
2025         (JSC::FTL::LowerDFGToLLVM::compileArithRound):
2026         * ftl/FTLOutput.h:
2027         (JSC::FTL::Output::ceil64):
2028         * jit/ThunkGenerators.cpp:
2029         * runtime/MathCommon.cpp:
2030         * runtime/MathCommon.h:
2031         * runtime/MathObject.cpp:
2032         (JSC::mathProtoFuncRound):
2033         * tests/stress/math-round-basics.js: Added.
2034         (mathRoundOnIntegers):
2035         (mathRoundOnDoubles):
2036         (mathRoundOnBooleans):
2037         (uselessMathRound):
2038         (mathRoundWithOverflow):
2039         (mathRoundConsumedAsDouble):
2040         (mathRoundDoesNotCareAboutMinusZero):
2041         (mathRoundNoArguments):
2042         (mathRoundTooManyArguments):
2043         (testMathRoundOnConstants):
2044         (mathRoundStructTransition):
2045         (Math.round):
2046
2047 2015-05-07  Saam Barati  <saambarati1@gmail.com>
2048
2049         exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
2050         https://bugs.webkit.org/show_bug.cgi?id=144753
2051
2052         Reviewed by Mark Lam.
2053
2054         This allows the BytecodeGenerator to freely emit startup code that "may"
2055         throw exceptions without worrying that this startup code will trigger
2056         the exceptionFuzz exception. The exceptionFuzz counter will only begin
2057         ticking when the 'enableExceptionFuzz' function is explicitly called in 
2058         the exceptionFuzz tests.
2059
2060         * jsc.cpp:
2061         (GlobalObject::finishCreation):
2062         (functionEnableExceptionFuzz):
2063         * tests/exceptionFuzz/3d-cube.js:
2064         * tests/exceptionFuzz/date-format-xparb.js:
2065         * tests/exceptionFuzz/earley-boyer.js:
2066
2067 2015-05-07  Andreas Kling  <akling@apple.com>
2068
2069         Optimize serialization of quoted JSON strings.
2070         <https://webkit.org/b/144754>
2071
2072         Reviewed by Darin Adler.
2073
2074         Optimized the serialization of quoted strings into JSON by moving the logic into
2075         StringBuilder so it can make smarter decisions about buffering.
2076
2077         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
2078
2079         * bytecompiler/NodesCodegen.cpp:
2080         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
2081
2082         * runtime/JSONObject.h:
2083         * runtime/JSONObject.cpp:
2084         (JSC::Stringifier::Holder::appendNextProperty):
2085         (JSC::appendStringToStringBuilder): Deleted.
2086         (JSC::appendQuotedJSONStringToBuilder): Deleted.
2087         (JSC::Stringifier::appendQuotedString): Deleted.
2088         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
2089         to StringBuilder and call that from here.
2090
2091 2015-05-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2092
2093         FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
2094         https://bugs.webkit.org/show_bug.cgi?id=144678
2095
2096         Reviewed by Geoffrey Garen.
2097
2098         Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
2099         But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
2100
2101         function t() { var ok = {null: function () { } }; ok[ok = null](); }
2102         t();  // Should not throw error.
2103
2104         This patch takes care about `subscriptHasAssignment`.
2105         By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
2106         it correctly moves the LHS value to a temporary register.
2107
2108         * bytecompiler/NodesCodegen.cpp:
2109         (JSC::FunctionCallBracketNode::emitBytecode):
2110         * parser/ASTBuilder.h:
2111         (JSC::ASTBuilder::makeFunctionCallNode):
2112         * parser/NodeConstructors.h:
2113         (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
2114         * parser/Nodes.h:
2115         * tests/stress/assignment-in-function-call-bracket-node.js: Added.
2116         (shouldBe):
2117         (shouldBe.):
2118
2119 2015-05-07  Basile Clement  <basile_clement@apple.com>
2120
2121         Unreviewed, add missing braces on a single-line if that got expanded in r183939
2122
2123         * ftl/FTLLowerDFGToLLVM.cpp:
2124         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2125
2126 2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>
2127
2128         Revert "Introducing the Platform Abstraction Layer (PAL)"
2129         https://bugs.webkit.org/show_bug.cgi?id=144751
2130
2131         Unreviewed.
2132
2133         PAL should be a new target inside WebCore, rather than a top-level folder.
2134
2135         * Configurations/FeatureDefines.xcconfig: Updated
2136
2137 2015-05-07  Basile Clement  <basile_clement@apple.com>
2138
2139         Dumping OSR ExitValue should expand materializations only once
2140         https://bugs.webkit.org/show_bug.cgi?id=144694
2141
2142         Reviewed by Filip Pizlo.
2143
2144         Currently, dumping OSR exit values will print the full materialization
2145         information each time it is encountered. We change it to print only a
2146         brief description (only the materialization's address), and print the
2147         whole set of materializations later on.
2148
2149         This makes the dump less confusing (less likely to think that two
2150         instances of the same materialization are different), and will be a
2151         necessary change if/when we support materialization cycles.
2152
2153         * ftl/FTLCompile.cpp:
2154         (JSC::FTL::mmAllocateDataSection):
2155         * ftl/FTLExitValue.cpp:
2156         (JSC::FTL::ExitValue::dumpInContext):
2157         * ftl/FTLLowerDFGToLLVM.cpp:
2158         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
2159
2160 2015-05-07  Andreas Kling  <akling@apple.com>
2161
2162         Worker threads leak WeakBlocks (as seen on leaks bot)
2163         <https://webkit.org/b/144721>
2164         <rdar://problem/20848288>
2165
2166         Reviewed by Darin Adler.
2167
2168         Nuke any remaining empty WeakBlocks when the Heap is being torn down.
2169         Trying to peek into these blocks after the VM is dead would be a bug anyway.
2170
2171         This fixes a ~750 KB leak seen on the leaks bot.
2172
2173         * heap/Heap.cpp:
2174         (JSC::Heap::~Heap):
2175
2176 2015-05-05  Geoffrey Garen  <ggaren@apple.com>
2177
2178         Don't branch when accessing the callee
2179         https://bugs.webkit.org/show_bug.cgi?id=144645
2180
2181         Reviewed by Michael Saboff.
2182
2183         The branch was added in <http://trac.webkit.org/changeset/81040> without
2184         explanation.
2185
2186         kling found it to be a performance problem. See <https://webkit.org/b/144586>.
2187
2188         Our theory of access to Registers is that it's up to the client to access
2189         them in the right way. So, let's do that.
2190
2191         * interpreter/CallFrame.h:
2192         (JSC::ExecState::callee):
2193         (JSC::ExecState::setCallee): Call the field object instead of function
2194         because nothing guarantees that it's a function.
2195         * interpreter/ProtoCallFrame.h:
2196         (JSC::ProtoCallFrame::callee):
2197         (JSC::ProtoCallFrame::setCallee):
2198         * interpreter/Register.h:
2199         * runtime/JSObject.h:
2200         (JSC::Register::object): Just do a cast like our other accessors do.
2201         (JSC::Register::operator=):
2202         (JSC::Register::function): Deleted.
2203         (JSC::Register::withCallee): Deleted.
2204
2205 2015-05-07  Dan Bernstein  <mitz@apple.com>
2206
2207         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
2208         https://bugs.webkit.org/show_bug.cgi?id=144727
2209
2210         Reviewed by Darin Adler.
2211
2212         * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
2213         INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
2214
2215 2015-05-07  Andreas Kling  <akling@apple.com>
2216
2217         Special-case Int32 values in JSON.stringify().
2218         <https://webkit.org/b/144731>
2219
2220         Reviewed by Michael Saboff.
2221
2222         Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
2223         simple integers through the full-blown dtoa() machinery.
2224
2225         ~50% speedup on Kraken/json-stringify-tinderbox.
2226
2227         * runtime/JSONObject.cpp:
2228         (JSC::Stringifier::appendStringifiedValue):
2229
2230 2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>
2231
2232         ToT WebKit crashes while loading ES6 compatibility table
2233         https://bugs.webkit.org/show_bug.cgi?id=144726
2234
2235         Reviewed by Filip Pizlo.
2236
2237         The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
2238
2239         Always build the identifier here as it could be a method name.
2240
2241         * parser/Parser.cpp:
2242         (JSC::Parser<LexerType>::parseClass):
2243
2244 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2245
2246         Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
2247         https://bugs.webkit.org/show_bug.cgi?id=144665
2248
2249         Reviewed by Michael Saboff.
2250         
2251         This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
2252         extending SaneChain to all indexing shapes.
2253
2254         * dfg/DFGFixupPhase.cpp:
2255         (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
2256         (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
2257         * dfg/DFGSpeculativeJIT.cpp:
2258         (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
2259         * dfg/DFGWatchpointCollectionPhase.cpp:
2260         (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
2261         (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
2262         * ftl/FTLLowerDFGToLLVM.cpp:
2263         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
2264
2265 2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>
2266
2267         Introducing the Platform Abstraction Layer (PAL)
2268         https://bugs.webkit.org/show_bug.cgi?id=143358
2269
2270         Reviewed by Simon Fraser.
2271
2272         * Configurations/FeatureDefines.xcconfig: Updated
2273
2274 2015-05-06  Andreas Kling  <akling@apple.com>
2275
2276         Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
2277         <https://webkit.org/b/144676>
2278
2279         Reviewed by Darin Adler.
2280
2281         We were creating a new String for every number JSValue passing through the JSON stringifier.
2282         These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
2283         Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
2284         for the conversion instead.
2285
2286         13% progression on Kraken/json-stringify-tinderbox.
2287
2288         * runtime/JSONObject.cpp:
2289         (JSC::Stringifier::appendStringifiedValue):
2290
2291 2015-05-06  Commit Queue  <commit-queue@webkit.org>
2292
2293         Unreviewed, rolling out r183847.
2294         https://bugs.webkit.org/show_bug.cgi?id=144691
2295
2296         Caused many assertion failures (Requested by ap on #webkit).
2297
2298         Reverted changeset:
2299
2300         "GC has trouble with pathologically large array allocations"
2301         https://bugs.webkit.org/show_bug.cgi?id=144609
2302         http://trac.webkit.org/changeset/183847
2303
2304 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2305
2306         PutGlobalVar shouldn't have an unconditional store barrier
2307         https://bugs.webkit.org/show_bug.cgi?id=133104
2308
2309         Reviewed by Benjamin Poulain.
2310         
2311         We don't need a store barrier on PutGlobalVar if the value being stored can be
2312         speculated to not be a cell.
2313
2314         * dfg/DFGFixupPhase.cpp:
2315         (JSC::DFG::FixupPhase::fixupNode):
2316
2317 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2318
2319         CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
2320         https://bugs.webkit.org/show_bug.cgi?id=144667
2321
2322         Reviewed by Andreas Kling.
2323         
2324         We are now calling this method for oversize blocks. It had an assertion that indirectly
2325         implied that the block is not oversize, because it was claiming that the number of live
2326         bytes should be smaller than the non-oversize-block size.
2327
2328         * heap/CopiedBlockInlines.h:
2329         (JSC::CopiedBlock::reportLiveBytes):
2330
2331 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2332
2333         GC has trouble with pathologically large array allocations
2334         https://bugs.webkit.org/show_bug.cgi?id=144609
2335
2336         Reviewed by Mark Lam.
2337
2338         * heap/Heap.cpp:
2339         (JSC::Heap::updateObjectCounts): Make this code less confusing.
2340         * heap/SlotVisitorInlines.h:
2341         (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.
2342         * jsc.cpp: Add size measuring hooks to write the largeish test.
2343         (GlobalObject::finishCreation):
2344         (functionGCAndSweep):
2345         (functionFullGC):
2346         (functionEdenGC):
2347         (functionHeapSize):
2348         * 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.
2349         * 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.
2350         (foo):
2351         (test):
2352
2353 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
2354
2355         FTL SwitchString slow case creates duplicate switch cases
2356         https://bugs.webkit.org/show_bug.cgi?id=144634
2357
2358         Reviewed by Geoffrey Garen.
2359         
2360         The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
2361         added mostly-debug-only asserts to catch such issues earlier.
2362
2363         * bytecode/CallVariant.cpp:
2364         (JSC::variantListWithVariant): Assertion to prevent similar bugs.
2365         * ftl/FTLLowerDFGToLLVM.cpp:
2366         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
2367         (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
2368         * jit/BinarySwitch.cpp:
2369         (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
2370         * jit/Repatch.cpp:
2371         (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
2372         * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
2373         (foo):
2374         (cat):
2375
2376 2015-05-05  Basile Clement  <basile_clement@apple.com>
2377
2378         Fix debug builds after r183812
2379         https://bugs.webkit.org/show_bug.cgi?id=144300
2380
2381         Rubber stamped by Andreas Kling and Filip Pizlo.
2382
2383         hasObjectMaterializationData() didn't treat MaterializeCreateActivation
2384         as having materialization data, which was causing an assertion failure when
2385         sinking CreateActivations on debug builds.
2386
2387         * dfg/DFGNode.h:
2388         (JSC::DFG::Node::hasObjectMaterializationData):
2389
2390 2015-05-04  Basile Clement  <basile_clement@apple.com>
2391
2392         Allow CreateActivation sinking
2393         https://bugs.webkit.org/show_bug.cgi?id=144300
2394
2395         Reviewed by Filip Pizlo.
2396
2397         This pursues the work started in
2398         https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
2399         allocations we are able to sink by allowing sinking of CreateActivation
2400         node.
2401
2402         This is achieved by following closely the way NewObject is currently
2403         sunk: we add a new PhantomCreateActivation node to record the initial
2404         position of the CreateActivation node, new ClosureVarPLoc promoted heap
2405         locations to keep track of the variables put in the activation, and a
2406         new MaterializeCreateActivation node to allocate and populate the sunk
2407         activation.
2408
2409         * dfg/DFGAbstractInterpreterInlines.h:
2410         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2411         * dfg/DFGClobberize.h:
2412         (JSC::DFG::clobberize):
2413         * dfg/DFGDoesGC.cpp:
2414         (JSC::DFG::doesGC):
2415         * dfg/DFGFixupPhase.cpp:
2416         (JSC::DFG::FixupPhase::fixupNode):
2417         * dfg/DFGNode.cpp:
2418         (JSC::DFG::Node::convertToPutClosureVarHint):
2419         * dfg/DFGNode.h:
2420         (JSC::DFG::Node::convertToPhantomCreateActivation):
2421         (JSC::DFG::Node::isActivationAllocation):
2422         (JSC::DFG::Node::isPhantomActivationAllocation):
2423         (JSC::DFG::Node::isPhantomAllocation):
2424         * dfg/DFGNodeType.h:
2425         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2426         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2427         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2428         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2429         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2430         * dfg/DFGPredictionPropagationPhase.cpp:
2431         (JSC::DFG::PredictionPropagationPhase::propagate):
2432         * dfg/DFGPromotedHeapLocation.cpp:
2433         (WTF::printInternal):
2434         * dfg/DFGPromotedHeapLocation.h:
2435         * dfg/DFGSafeToExecute.h:
2436         (JSC::DFG::safeToExecute):
2437         * dfg/DFGSpeculativeJIT32_64.cpp:
2438         (JSC::DFG::SpeculativeJIT::compile):
2439         * dfg/DFGSpeculativeJIT64.cpp:
2440         (JSC::DFG::SpeculativeJIT::compile):
2441         * dfg/DFGValidate.cpp:
2442         (JSC::DFG::Validate::validateCPS):
2443         * ftl/FTLCapabilities.cpp:
2444         (JSC::FTL::canCompile):
2445         * ftl/FTLLowerDFGToLLVM.cpp:
2446         (JSC::FTL::LowerDFGToLLVM::compileNode):
2447         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
2448         * ftl/FTLOperations.cpp:
2449         (JSC::FTL::operationMaterializeObjectInOSR):
2450         * tests/stress/activation-sink-osrexit.js: Added.
2451         (bar):
2452         (foo.set result):
2453         * tests/stress/activation-sink.js: Added.
2454         (bar):
2455
2456 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2457
2458         Unreviewed, fix stale comment.
2459
2460         * tests/mozilla/js1_5/Array/regress-101964.js:
2461
2462 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2463
2464         Large array shouldn't be slow
2465         https://bugs.webkit.org/show_bug.cgi?id=144617
2466
2467         Rubber stamped by Mark Lam.
2468
2469         * 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.
2470
2471 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2472
2473         Large array shouldn't be slow
2474         https://bugs.webkit.org/show_bug.cgi?id=144617
2475
2476         Rubber stamped by Mark Lam.
2477
2478         * 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.
2479
2480 2015-05-04  Commit Queue  <commit-queue@webkit.org>
2481
2482         Unreviewed, rolling out r183789.
2483         https://bugs.webkit.org/show_bug.cgi?id=144620
2484
2485         Causing flakiness on exceptionFuzz tests locally on 32-bit
2486         build (Requested by saamyjoon on #webkit).
2487
2488         Reverted changeset:
2489
2490         "Global functions should be initialized as JSFunctions in byte
2491         code"
2492         https://bugs.webkit.org/show_bug.cgi?id=144178
2493         http://trac.webkit.org/changeset/183789
2494
2495 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2496
2497         Global functions should be initialized as JSFunctions in byte code
2498         https://bugs.webkit.org/show_bug.cgi?id=144178
2499
2500         Reviewed by Geoffrey Garen.
2501
2502         This patch makes the initialization of global functions more explicit by
2503         moving initialization into bytecode. It also prepares JSC for having ES6
2504         style lexical scoping because initializing global functions in bytecode
2505         easily allows global functions to be initialized with the proper scope that
2506         will have access to global lexical variables. Global lexical variables
2507         should be visible to global functions but don't live on the global object.
2508
2509         * bytecode/UnlinkedCodeBlock.cpp:
2510         (JSC::UnlinkedProgramCodeBlock::visitChildren):
2511         * bytecode/UnlinkedCodeBlock.h:
2512         * bytecompiler/BytecodeGenerator.cpp:
2513         (JSC::BytecodeGenerator::generate):
2514         (JSC::BytecodeGenerator::BytecodeGenerator):
2515         * bytecompiler/BytecodeGenerator.h:
2516         * runtime/Executable.cpp:
2517         (JSC::ProgramExecutable::initializeGlobalProperties):
2518         * runtime/JSGlobalObject.cpp:
2519         (JSC::JSGlobalObject::addGlobalVar):
2520         (JSC::JSGlobalObject::addFunction):
2521         * runtime/JSGlobalObject.h:
2522
2523 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2524
2525         Large array shouldn't be slow
2526         https://bugs.webkit.org/show_bug.cgi?id=144617
2527
2528         Reviewed by Geoffrey Garen.
2529         
2530         Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
2531         you're already using ArrayStorage mode, from the minimul array length required to use
2532         ArrayStorage in a new Array(length) allocation.
2533         
2534         Lift the array allocation length threshold to something very high. If this works, we'll
2535         probably remove that threshold entirely.
2536         
2537         This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
2538         JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
2539         for now.
2540
2541         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2542         * dfg/DFGSpeculativeJIT32_64.cpp:
2543         (JSC::DFG::SpeculativeJIT::compile):
2544         * dfg/DFGSpeculativeJIT64.cpp:
2545         (JSC::DFG::SpeculativeJIT::compile):
2546         * ftl/FTLLowerDFGToLLVM.cpp:
2547         (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
2548         * runtime/ArrayConventions.h:
2549         * runtime/JSArray.h:
2550         (JSC::JSArray::create):
2551         * runtime/JSGlobalObject.h:
2552         (JSC::constructEmptyArray):
2553         * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
2554
2555 2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2556
2557         Add backed intrinsics to private functions exposed with private symbols in global object
2558         https://bugs.webkit.org/show_bug.cgi?id=144545
2559
2560         Reviewed by Darin Adler.
2561
2562         Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
2563         This patch adds intrinsic to private functions exposed with private symbols in global object,
2564         @floor and @abs.
2565
2566         * runtime/JSGlobalObject.cpp:
2567         (JSC::JSGlobalObject::init):
2568         * runtime/JSGlobalObjectFunctions.cpp:
2569         (JSC::globalPrivateFuncAbs): Deleted.
2570         (JSC::globalPrivateFuncFloor): Deleted.
2571         * runtime/MathObject.cpp:
2572         * runtime/MathObject.h:
2573         * tests/stress/array-from-abs-and-floor.js: Added.
2574         (target1):
2575         (target2):
2576         (target3):
2577
2578 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2579
2580         [cmake] ARM related build system cleanup
2581         https://bugs.webkit.org/show_bug.cgi?id=144566
2582
2583         Reviewed by Darin Adler.
2584
2585         * CMakeLists.txt:
2586
2587 2015-05-04  Andreas Kling  <akling@apple.com>
2588
2589         Optimize WeakBlock's "reap" and "visit" operations.
2590         <https://webkit.org/b/144585>
2591
2592         Reviewed by Geoffrey Garen.
2593
2594         WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
2595         That function was really written with conservative roots marking in mind, and will do a bunch
2596         of sanity and bounds checks.
2597
2598         For weaks, we know that the pointer will have been a valid cell pointer into a block
2599         of appropriate cell size, so we can skip a lot of the checks.
2600
2601         We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
2602         MarkedBlock::blockFor() for every single cell when iterating.
2603
2604         Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
2605         WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
2606         be pointing to any live cells, and the only operation that will run on the block is sweep().
2607
2608         Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
2609         In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
2610         This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
2611
2612         This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
2613         what looks like a 1% speedup locally.
2614
2615         * heap/MarkedBlock.cpp:
2616         (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
2617
2618         * heap/MarkedBlock.h:
2619         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
2620         block's state is known to be either Marked or Retired.
2621
2622         (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
2623         would report that all cells are live anyway.
2624
2625         * heap/WeakBlock.cpp:
2626         (JSC::WeakBlock::create):
2627         (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
2628
2629         (JSC::WeakBlock::visit):
2630         (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
2631
2632         * heap/WeakBlock.h:
2633         (JSC::WeakBlock::disconnectMarkedBlock): Added.
2634         * heap/WeakSet.cpp:
2635         (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
2636         ownership to Heap until it can die peacefully.
2637
2638         (JSC::WeakSet::addAllocator):
2639         * heap/WeakSet.h:
2640         (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
2641
2642 2015-05-04  Basile Clement  <basile_clement@apple.com>
2643
2644         Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
2645         https://bugs.webkit.org/show_bug.cgi?id=144587
2646
2647         Rubber stamped by Filip Pizlo.
2648
2649         When sinking object allocations, we ensure in
2650         determineMaterializationPoints that whenever an allocation is
2651         materialized on a path to a block, it is materialized in all such
2652         paths. Thus when running the SSA calculator to place Phis in
2653         placeMaterializationPoints, we can't encounter a situation where some
2654         Upsilons are referring to a materialization while others are referring
2655         to the phantom object.
2656
2657         This replaces the code that was adding a materialization late in
2658         placeMaterializationPoints to handle that case by an assertion that it
2659         does not happen, which will make
2660         https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
2661
2662         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2663         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2664
2665 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2666
2667         Extending undefined in class syntax should throw a TypeError
2668         https://bugs.webkit.org/show_bug.cgi?id=144284
2669
2670         Reviewed by Darin Adler.
2671
2672         The bug was caused by op_eq_null evaluating to true when compared to undefined.
2673         Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
2674
2675         We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
2676
2677         * bytecompiler/NodesCodegen.cpp:
2678         (JSC::ClassExprNode::emitBytecode):
2679
2680 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2681
2682         new super should be a syntax error
2683         https://bugs.webkit.org/show_bug.cgi?id=144282
2684
2685         Reviewed by Joseph Pecoraro.
2686
2687         Disallow "new super" as ES6 spec doesn't allow this.
2688
2689         * parser/Parser.cpp:
2690         (JSC::Parser<LexerType>::parseMemberExpression):
2691
2692 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2693
2694         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
2695         https://bugs.webkit.org/show_bug.cgi?id=144265
2696
2697         Reviewed by Geoffrey Garen.
2698
2699         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
2700         for a static function if the parent has that property slot. JSCallbackObject::put 
2701         did not maintain this symmetry of also calling ::put on the parent if the parent 
2702         has the property. We should ensure that this symmetry exists.
2703
2704         * API/JSCallbackObjectFunctions.h:
2705         (JSC::JSCallbackObject<Parent>::put):
2706         * API/tests/testapi.c:
2707         * API/tests/testapi.js:
2708         (globalStaticFunction2):
2709         (this.globalStaticFunction2):
2710         (iAmNotAStaticFunction):
2711         (this.iAmNotAStaticFunction):
2712
2713 2015-05-04  Andreas Kling  <akling@apple.com>
2714
2715         Make ExecState::vm() branchless in release builds.
2716         <https://webkit.org/b/144586>
2717
2718         Reviewed by Geoffrey Garen.
2719
2720         Avoid null checking the ExecState's callee() before getting the
2721         VM from it. The code was already dereferencing it anyway, since we
2722         know it's not gonna be null.
2723
2724         * runtime/JSCellInlines.h:
2725         (JSC::ExecState::vm):
2726
2727 2015-05-04  Basile Clement  <basile_clement@apple.com>
2728
2729         Object allocation not sinking properly through CheckStructure
2730         https://bugs.webkit.org/show_bug.cgi?id=144465
2731
2732         Reviewed by Filip Pizlo.
2733
2734         Currently, sinking an allocation through a CheckStructure will
2735         completely ignore all structure checking, which is obviously wrong.
2736
2737         A CheckStructureImmediate node type was present for that purpose, but
2738         the CheckStructures were not properly replaced.  This ensures that
2739         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
2740         sunk through, and that structure checking happens correctly.
2741
2742         * dfg/DFGNode.h:
2743         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
2744         (JSC::DFG::Node::hasStructureSet):
2745         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2746         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2747         * ftl/FTLLowerDFGToLLVM.cpp:
2748         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
2749         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
2750         (JSC::FTL::LowerDFGToLLVM::checkStructure):
2751         * tests/stress/sink_checkstructure.js: Added.
2752         (foo):
2753
2754 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
2755
2756         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
2757         https://bugs.webkit.org/show_bug.cgi?id=144476
2758
2759         Reviewed by Sam Weinig.
2760
2761         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
2762
2763         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
2764         to my knowledge, the topic of how to optimize it is not covered in any
2765         literature about sorting.
2766
2767         On the slowest jQuery sorting test -- prevAll -- our new
2768         Array.prototype.sort, compared to its predecessor, performed 12% fewer
2769         comparisons and requireed 10X less overhead per comparison. Yet, it was
2770         slower.
2771
2772         It was slower because it inadvertantly increased the average cost of the
2773         comparison function by 2X. jQuery uses compareDocumentPosition to compare
2774         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
2775         required to traverse backwards from b to a. In prevAll, we encounter the
2776         worst case for merge sort of compareDocumentPosition: A long list of DOM
2777         nodes in mostly reverse order. In this case, merge sort will sequentially
2778         compareDocumentPosition(a, b), where a is not reachable backwards from
2779         b, and therefore compareDocumentPosition will traverse the whole sibling
2780         list.
2781
2782         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
2783
2784         This is a pretty silly thing to do, but it is harmless, and jQuery is
2785         popular, so let's do it.
2786
2787         We do not risk suffering the same problem in reverse when sorting a long
2788         list of DOM nodes in forward order. (We still have a 37% speedup on the
2789         nextAll benchmark.) The reason is that merge sort performs 2X fewer
2790         comparisons when the list is already sorted, so we can worry less about
2791         the cost of each comparison.
2792
2793         A fully principled soultion to this problem would probably do something
2794         like Python's timsort, which special-cases ordered ranges to perform
2795         only O(n) comparisons. But that would contradict our original
2796         goal of just having something simple that works.
2797
2798         Another option is for elements to keep a compareDocumentPosition cache,
2799         like a node list cache, which allows you to determine the absolute
2800         position of a node using a hash lookup. I will leave this as an exercise
2801         for kling.
2802
2803         * builtins/Array.prototype.js:
2804         (sort.merge): Compare in an order that is favorable to a comparator
2805         that calls compareDocumentPosition.
2806
2807 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2808
2809         [cmake] Fix generate-js-builtins related incremental build issue
2810         https://bugs.webkit.org/show_bug.cgi?id=144094
2811
2812         Reviewed by Michael Saboff.
2813
2814         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
2815         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2816         * DerivedSources.make:
2817         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2818         * generate-js-builtins: Accept input files and input directory too.
2819
2820 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
2821
2822         Make some static data const
2823         https://bugs.webkit.org/show_bug.cgi?id=144552
2824
2825         Reviewed by Andreas Kling.
2826         
2827         Turn characterSetInfo into const data.
2828
2829         * yarr/YarrCanonicalizeUCS2.cpp:
2830         * yarr/YarrCanonicalizeUCS2.h:
2831
2832 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2833
2834         TypeOf should be fast
2835         https://bugs.webkit.org/show_bug.cgi?id=144396
2836
2837         Reviewed by Geoffrey Garen.
2838         
2839         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
2840         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
2841         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
2842         
2843         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
2844         rely heavily on C++ calls to fulfill their function.
2845         
2846         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
2847         
2848         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
2849         This means that if the TypeOf is dominated by any type checks, we will automatically prune
2850         out cases that are redundant.
2851         
2852         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
2853         code generation is designed to be reusable.
2854         
2855         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
2856         the exotic call trap hook. That hook is now in a deeper slow path than before.
2857
2858         * CMakeLists.txt:
2859         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2860         * JavaScriptCore.xcodeproj/project.pbxproj:
2861         * dfg/DFGClobberize.h:
2862         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
2863         * dfg/DFGFixupPhase.cpp:
2864         (JSC::DFG::FixupPhase::fixupNode):
2865         * dfg/DFGHeapLocation.cpp:
2866         (WTF::printInternal):
2867         * dfg/DFGHeapLocation.h:
2868         * dfg/DFGOperations.cpp:
2869         * dfg/DFGOperations.h:
2870         * dfg/DFGSpeculativeJIT.cpp:
2871         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
2872         (JSC::DFG::SpeculativeJIT::compileIsFunction):
2873         (JSC::DFG::SpeculativeJIT::compileTypeOf):
2874         * dfg/DFGSpeculativeJIT.h:
2875         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
2876         (JSC::DFG::SpeculativeJIT::callOperation):
2877         * dfg/DFGSpeculativeJIT32_64.cpp:
2878         (JSC::DFG::SpeculativeJIT::compile):
2879         * dfg/DFGSpeculativeJIT64.cpp:
2880         (JSC::DFG::SpeculativeJIT::compile):
2881         * ftl/FTLCapabilities.cpp:
2882         (JSC::FTL::canCompile):
2883         * ftl/FTLIntrinsicRepository.h:
2884         * ftl/FTLLowerDFGToLLVM.cpp:
2885         (JSC::FTL::LowerDFGToLLVM::compileNode):
2886         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
2887         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
2888         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
2889         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
2890         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
2891         * ftl/FTLSwitchCase.h:
2892         (JSC::FTL::SwitchCase::SwitchCase):
2893         * jit/AssemblyHelpers.h:
2894         (JSC::AssemblyHelpers::branchIfNotEqual):
2895         (JSC::AssemblyHelpers::branchIfEqual):
2896         (JSC::AssemblyHelpers::branchIfNumber):
2897         (JSC::AssemblyHelpers::branchIfNotNumber):
2898         (JSC::AssemblyHelpers::branchIfBoolean):
2899         (JSC::AssemblyHelpers::branchIfNotBoolean):
2900         (JSC::AssemblyHelpers::boxBooleanPayload):
2901         (JSC::AssemblyHelpers::boxBoolean):
2902         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
2903         * jit/JITOperations.h:
2904         * runtime/SmallStrings.h:
2905         (JSC::SmallStrings::typeString):
2906         * runtime/TypeofType.cpp: Added.
2907         (WTF::printInternal):
2908         * runtime/TypeofType.h: Added.
2909         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
2910
2911 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2912
2913         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
2914
2915         * dfg/DFGLICMPhase.cpp:
2916         (JSC::DFG::LICMPhase::attemptHoist):
2917
2918 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2919
2920         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
2921         https://bugs.webkit.org/show_bug.cgi?id=144525.
2922
2923         * dfg/DFGLICMPhase.cpp:
2924         (JSC::DFG::LICMPhase::attemptHoist):
2925         * dfg/DFGPhantomInsertionPhase.cpp:
2926
2927 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
2928
2929         Static property hashtable should only lookup with non-symbol key
2930         https://bugs.webkit.org/show_bug.cgi?id=144438
2931
2932         Reviewed by Darin Adler.
2933
2934         Static property hashtable compares the Identifier's uid
2935         with the normal C string without interning it.
2936         So this comparison is performed in their contents.
2937         As the result, in this comparison, symbol-ness is not considered.
2938
2939         So if accidentally the hash collision occur with the symbol and the string
2940         and they have the same contents, the hash table entry is looked up incorrectly.
2941
2942         * runtime/Lookup.h:
2943         (JSC::HashTable::entry):
2944
2945 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
2946
2947         Class syntax should allow string and numeric identifiers for method names
2948         https://bugs.webkit.org/show_bug.cgi?id=144254
2949
2950         Reviewed by Darin Adler.
2951
2952         Added the support for string and numeric identifiers in class syntax.
2953
2954         * parser/Parser.cpp:
2955         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
2956         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
2957         outside a class constructor as it should be.
2958         (JSC::Parser<LexerType>::parseFunctionDeclaration):
2959         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
2960         element to allow numeric and string method names. For both of those method names, parse it here instead
2961         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
2962         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
2963         this function is never used to parse a class method.
2964         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
2965         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
2966         * parser/Parser.h:
2967         * parser/SyntaxChecker.h:
2968         (JSC::SyntaxChecker::createProperty):
2969
2970 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2971
2972         FTL should use AI more
2973         https://bugs.webkit.org/show_bug.cgi?id=144500
2974
2975         Reviewed by Oliver Hunt.
2976         
2977         This makes our type check folding even more comprehensive by ensuring that even if the FTL
2978         decides to emit some checks, it will still do another query to the abstract interpreter to
2979         see if the check is necessary. This helps with cases where we decided early on to speculate
2980         one way, but later proved a more specific type of the value in question, and the constant
2981         folder didn't catch it.
2982         
2983         This also makes it more natural to query the abstract interpreter. For example, if you just
2984         want the proven type, you can now say provenType(node) or provenType(edge).
2985
2986         * dfg/DFGArrayMode.cpp:
2987         (JSC::DFG::ArrayMode::alreadyChecked):
2988         * dfg/DFGArrayMode.h:
2989         * ftl/FTLLowerDFGToLLVM.cpp:
2990         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
2991         (JSC::FTL::LowerDFGToLLVM::compileToThis):
2992         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
2993         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
2994         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
2995         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2996         (JSC::FTL::LowerDFGToLLVM::compileGetById):
2997         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
2998         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
2999         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
3000         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
3001         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
3002         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
3003         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
3004         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
3005         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
3006         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
3007         (JSC::FTL::LowerDFGToLLVM::compileIsString):
3008         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
3009         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
3010         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
3011         (JSC::FTL::LowerDFGToLLVM::baseIndex):
3012         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
3013         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
3014         (JSC::FTL::LowerDFGToLLVM::boolify):
3015         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
3016         (JSC::FTL::LowerDFGToLLVM::lowInt32):
3017         (JSC::FTL::LowerDFGToLLVM::lowInt52):
3018         (JSC::FTL::LowerDFGToLLVM::lowCell):
3019         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
3020         (JSC::FTL::LowerDFGToLLVM::lowDouble):
3021         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
3022         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
3023         (JSC::FTL::LowerDFGToLLVM::isNumber):
3024         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
3025         (JSC::FTL::LowerDFGToLLVM::isNotCell):
3026         (JSC::FTL::LowerDFGToLLVM::isCell):
3027         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
3028         (JSC::FTL::LowerDFGToLLVM::isMisc):
3029         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
3030         (JSC::FTL::LowerDFGToLLVM::isBoolean):
3031         (JSC::FTL::LowerDFGToLLVM::isNotOther):
3032         (JSC::FTL::LowerDFGToLLVM::isOther):
3033         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
3034         (JSC::FTL::LowerDFGToLLVM::isObject):
3035         (JSC::FTL::LowerDFGToLLVM::isNotObject):
3036         (JSC::FTL::LowerDFGToLLVM::isNotString):
3037         (JSC::FTL::LowerDFGToLLVM::isString):
3038         (JSC::FTL::LowerDFGToLLVM::isFunction):
3039         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
3040         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
3041         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
3042         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
3043         (JSC::FTL::LowerDFGToLLVM::abstractValue):
3044         (JSC::FTL::LowerDFGToLLVM::provenType):
3045         (JSC::FTL::LowerDFGToLLVM::provenValue):
3046         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
3047
3048 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
3049
3050         USE(...) macro should expect unprefixed variables
3051         https://bugs.webkit.org/show_bug.cgi?id=144454
3052
3053         Reviewed by Daniel Bates.
3054
3055         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
3056
3057 2015-05-01  Jordan Harband  <ljharb@gmail.com>
3058
3059         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
3060         https://bugs.webkit.org/show_bug.cgi?id=144314
3061
3062         Reviewed by Darin Adler.
3063
3064         Fixing handling of Infinity position args, per
3065         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
3066         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
3067         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
3068
3069         * runtime/StringPrototype.cpp:
3070         (JSC::clampInt32):
3071         (JSC::stringProtoFuncStartsWith):
3072         (JSC::stringProtoFuncEndsWith):
3073         (JSC::stringProtoFuncIncludes):
3074
3075 2015-05-01  Basile Clement  <basile_clement@apple.com>
3076
3077         Math.abs() returns negative
3078         https://bugs.webkit.org/show_bug.cgi?id=137827
3079
3080         Reviewed by Michael Saboff.
3081
3082         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
3083         identity function.
3084
3085         * dfg/DFGAbstractInterpreterInlines.h:
3086         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3087         * tests/stress/math-abs-positive.js: Added, was previously failing.
3088         (foo):
3089
3090 2015-05-01  Basile Clement  <basile_clement@apple.com>
3091
3092         Function allocation sinking shouldn't be performed on singleton functions
3093         https://bugs.webkit.org/show_bug.cgi?id=144166
3094
3095         Reviewed by Geoffrey Garen.
3096
3097         Function allocations usually are free of any other side effects, but
3098         this is not the case for allocations performed while the underlying
3099         FunctionExecutable is still a singleton (as this allogation will fire
3100         watchpoints invalidating code that depends on it being a singleton).
3101         As the object allocation sinking phase assumes object allocation is
3102         free of side-effects, sinking these allocations is not correct.
3103
3104         This also means that when materializing a function allocation on OSR
3105         exit, that function's executable will never be a singleton, and we don't have
3106         to worry about its watchpoint, allowing us to use
3107         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
3108         JSFunction::create.
3109
3110         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3111         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
3112         * ftl/FTLOperations.cpp:
3113         (JSC::FTL::operationMaterializeObjectInOSR):
3114
3115 2015-04-30  Jon Davis  <jond@apple.com>
3116
3117         Web Inspector: console should show an icon for console.info() messages
3118         https://bugs.webkit.org/show_bug.cgi?id=18530
3119
3120         Reviewed by Timothy Hatcher.
3121
3122         * inspector/ConsoleMessage.cpp:
3123         (Inspector::messageLevelValue):
3124         * inspector/protocol/Console.json:
3125         * runtime/ConsoleClient.cpp:
3126         (JSC::appendMessagePrefix):
3127         * runtime/ConsolePrototype.cpp:
3128         (JSC::ConsolePrototype::finishCreation):
3129         (JSC::consoleProtoFuncInfo):
3130         * runtime/ConsoleTypes.h:
3131
3132 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3133
3134         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
3135         https://bugs.webkit.org/show_bug.cgi?id=144462
3136
3137         Reviewed by Geoffrey Garen and Mark Lam.
3138         
3139         At some point we started adding representation-agnostic helpers for doing common type tests.
3140         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
3141         they had overlapping powers, though SpeculativeJIT was a bit better.
3142         
3143         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
3144         better because now all of these helpers can be used in all of the assembly-based JITs, not
3145         just the DFG. It also settles on what I find to be a slightly better naming convention.
3146         For example where we previously would have said branchIsString, now we say
3147         branchIfString. Similarly, branchNotString becomes branchIfNotString.
3148
3149         * dfg/DFGSpeculativeJIT.cpp:
3150         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
3151         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3152         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
3153         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
3154         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
3155         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
3156         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
3157         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
3158         (JSC::DFG::SpeculativeJIT::speculateObject):
3159         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
3160         (JSC::DFG::SpeculativeJIT::speculateString):
3161         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
3162         (JSC::DFG::SpeculativeJIT::speculateNotCell):
3163         (JSC::DFG::SpeculativeJIT::speculateOther):
3164         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
3165         (JSC::DFG::SpeculativeJIT::emitSwitchString):
3166         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
3167         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
3168         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
3169         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
3170         * dfg/DFGSpeculativeJIT.h:
3171         * dfg/DFGSpeculativeJIT32_64.cpp:
3172         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3173         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3174         (JSC::DFG::SpeculativeJIT::emitCall):
3175         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
3176         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3177         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3178         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3179         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3180         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3181         (JSC::DFG::SpeculativeJIT::compile):
3182         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
3183         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
3184         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
3185         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
3186         * dfg/DFGSpeculativeJIT64.cpp:
3187         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
3188         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
3189         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
3190         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3191         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3192         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3193         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3194         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3195         (JSC::DFG::SpeculativeJIT::compile):
3196         (JSC::DFG::SpeculativeJIT::writeBarrier):
3197         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
3198         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
3199         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
3200         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
3201         * jit/AssemblyHelpers.h:
3202         (JSC::AssemblyHelpers::branchIfCell):
3203         (JSC::AssemblyHelpers::branchIfOther):
3204         (JSC::AssemblyHelpers::branchIfNotOther):
3205         (JSC::AssemblyHelpers::branchIfObject):
3206         (JSC::AssemblyHelpers::branchIfNotObject):
3207         (JSC::AssemblyHelpers::branchIfType):
3208         (JSC::AssemblyHelpers::branchIfNotType):
3209         (JSC::AssemblyHelpers::branchIfString):
3210         (JSC::AssemblyHelpers::branchIfNotString):
3211         (JSC::AssemblyHelpers::branchIfSymbol):
3212         (JSC::AssemblyHelpers::branchIfNotSymbol):
3213         (JSC::AssemblyHelpers::branchIfFunction):
3214         (JSC::AssemblyHelpers::branchIfNotFunction):
3215         (JSC::AssemblyHelpers::branchIfEmpty):
3216         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
3217         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
3218         * jit/JITPropertyAccess.cpp:
3219         (JSC::JIT::emitScopedArgumentsGetByVal):
3220
3221 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3222
3223         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
3224         https://bugs.webkit.org/show_bug.cgi?id=144463
3225
3226         Reviewed by Benjamin Poulain.
3227         
3228         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
3229         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
3230         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
3231         converting the boolean into an integer. But as part of doing that, it would try to
3232         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
3233         and it would try to figure out if the addition might overflow. Part of that logic
3234         involved checking if the immediate is either a boolean or a sufficiently small integer.
3235         But: it would check if it's a sufficiently small integer before checking if it was a
3236         boolean, so it would try to call asNumber() on the boolean.
3237         
3238         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
3239         case was previously never hit until I wrote these tests, and so we never knew that
3240         calling asNumber() on a boolean was wrong.
3241         
3242         The fix is super simple: the expression should just check for boolean first.
3243         
3244         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
3245         garbage, and that's OK, since we'd take the boolean case anyway.
3246
3247         * dfg/DFGGraph.h:
3248         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
3249
3250 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3251
3252         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
3253
3254         * jit/JITOperations.cpp:
3255
3256 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
3257
3258         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
3259         particular that they cannot change their minds and may be called from compiler threads.
3260
3261         Rubber stamped by Geoffrey Garen.
3262
3263         * runtime/JSCell.h:
3264
3265 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
3266
3267         DFG Is<Blah> versions of TypeOf should fold based on proven input type
3268         https://bugs.webkit.org/show_bug.cgi?id=144409
3269
3270         Reviewed by Geoffrey Garen.
3271         
3272         We were missing some obvious folding opportunities here. I don't know how this affects real
3273         code, but in general, we like to ensure that our constant folding is comprehensive. So this
3274         is more about placating my static analysis OCD than anything else.
3275         
3276         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
3277
3278         * dfg/DFGAbstractInterpreterInlines.h:
3279         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3280
3281 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
3282
3283         Use the default hash value for Symbolized StringImpl
3284         https://bugs.webkit.org/show_bug.cgi?id=144347
3285
3286         Reviewed by Darin Adler.
3287
3288         Before this patch, symbolized StringImpl* has a special hash value
3289         to avoid the hash collision with the other normal StringImpl*.
3290         I guess that it is introduced when private symbols are introduced.
3291         However, it prevents using symbolized StringImpl* in the other place
3292         For example, using it as WTFString cause a problem because of its special hash value.
3293
3294         When only using private symbols, they are not exposed to the outside of JSC,
3295         so we can handle it carefully. But now, it's extended to symbols.
3296         So I think storing a special hash value in StringImpl* causes an error.
3297
3298         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
3299         And to provide significantly different hash value when using it as symbol,
3300         store the additional hash value in symbolized StringImpl*. It is used when
3301         the hash value is required by IdentifierRepHash.
3302
3303         * runtime/Identifier.h:
3304         (JSC::IdentifierRepHash::hash):
3305         * runtime/Lookup.h:
3306         (JSC::HashTable::entry):
3307         * runtime/PropertyMapHashTable.h:
3308         (JSC::PropertyTable::find):
3309         (JSC::PropertyTable::get):
3310         * runtime/Structure.cpp:
3311         (JSC::PropertyTable::checkConsistency):
3312
3313 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
3314
3315         [JSC] Remove RageConvert array conversion
3316         https://bugs.webkit.org/show_bug.cgi?id=144433
3317
3318         Reviewed by Filip Pizlo.
3319
3320         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
3321         pretty hard:
3322         -The indexing types shows that the array access varies between Int32 and DoubleArray.
3323         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.