[JSC] Should check Test262Error correctly
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-07-31  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [JSC] Should check Test262Error correctly
4         https://bugs.webkit.org/show_bug.cgi?id=159862
5
6         Reviewed by Saam Barati.
7
8         Test262Error in the harness does not have "name" property.
9         Rather than checking "name" property, peforming `instanceof` is better to check the class of the exception.
10
11         * jsc.cpp:
12         (checkUncaughtException):
13         * runtime/JSObject.h:
14         * tests/test262.yaml:
15
16 2016-07-31  Yusuke Suzuki  <utatane.tea@gmail.com>
17
18         [ES6] Module binding can be exported by multiple names
19         https://bugs.webkit.org/show_bug.cgi?id=160343
20
21         Reviewed by Saam Barati.
22
23         ES6 Module can export the same local binding by using multiple names.
24         For example,
25
26             ```
27             var value = 42;
28
29             export { value };
30             export { value as value2 };
31             ```
32
33         Currently, we only allowed one local binding to be exported with one name. So, in the above case,
34         the local binding "value" is exported as "value2" and "value" name is not exported. This is wrong.
35
36         To fix this issue, we collect the correspondence (local name => exported name) to the local bindings
37         in the parser. Previously, we only maintained the exported local bindings in the parser. And utilize
38         this information when creating the export entries in ModuleAnalyzer.
39
40         And this patch also moves ModuleScopeData from the Scope object to the Parser class since exported
41         names should be managed per-module, not per-scope.
42
43         This change fixes several test262 failures.
44
45         * JavaScriptCore.xcodeproj/project.pbxproj:
46         * parser/ModuleAnalyzer.cpp:
47         (JSC::ModuleAnalyzer::exportVariable):
48         (JSC::ModuleAnalyzer::analyze):
49         (JSC::ModuleAnalyzer::exportedBinding): Deleted.
50         (JSC::ModuleAnalyzer::declareExportAlias): Deleted.
51         * parser/ModuleAnalyzer.h:
52         * parser/ModuleScopeData.h: Copied from Source/JavaScriptCore/parser/ModuleAnalyzer.h.
53         (JSC::ModuleScopeData::create):
54         (JSC::ModuleScopeData::exportedBindings):
55         (JSC::ModuleScopeData::exportName):
56         (JSC::ModuleScopeData::exportBinding):
57         * parser/Nodes.cpp:
58         (JSC::ProgramNode::ProgramNode):
59         (JSC::ModuleProgramNode::ModuleProgramNode):
60         (JSC::EvalNode::EvalNode):
61         (JSC::FunctionNode::FunctionNode):
62         * parser/Nodes.h:
63         (JSC::ModuleProgramNode::moduleScopeData):
64         * parser/NodesAnalyzeModule.cpp:
65         (JSC::ExportDefaultDeclarationNode::analyzeModule):
66         (JSC::ExportNamedDeclarationNode::analyzeModule): Deleted.
67         * parser/Parser.cpp:
68         (JSC::Parser<LexerType>::Parser):
69         (JSC::Parser<LexerType>::parseModuleSourceElements):
70         (JSC::Parser<LexerType>::parseVariableDeclarationList):
71         (JSC::Parser<LexerType>::createBindingPattern):
72         (JSC::Parser<LexerType>::parseFunctionDeclaration):
73         (JSC::Parser<LexerType>::parseClassDeclaration):
74         (JSC::Parser<LexerType>::parseExportSpecifier):
75         (JSC::Parser<LexerType>::parseExportDeclaration):
76         * parser/Parser.h:
77         (JSC::Parser::exportName):
78         (JSC::Parser<LexerType>::parse):
79         (JSC::ModuleScopeData::create): Deleted.
80         (JSC::ModuleScopeData::exportedBindings): Deleted.
81         (JSC::ModuleScopeData::exportName): Deleted.
82         (JSC::ModuleScopeData::exportBinding): Deleted.
83         (JSC::Scope::Scope): Deleted.
84         (JSC::Scope::setSourceParseMode): Deleted.
85         (JSC::Scope::moduleScopeData): Deleted.
86         (JSC::Scope::setIsModule): Deleted.
87         * tests/modules/aliased-names.js: Added.
88         * tests/modules/aliased-names/main.js: Added.
89         (change):
90         * tests/stress/modules-syntax-error-with-names.js:
91         (export.Cocoa):
92         (SyntaxError.Cannot.export.a.duplicate.name):
93         * tests/test262.yaml:
94
95 2016-07-30  Mark Lam  <mark.lam@apple.com>
96
97         Assertion failure while setting the length of an ArrayClass array.
98         https://bugs.webkit.org/show_bug.cgi?id=160381
99         <rdar://problem/27328703>
100
101         Reviewed by Filip Pizlo.
102
103         When setting large length values, we're currently treating ArrayClass as a
104         ContiguousIndexingType array.  This results in an assertion failure.  This is
105         now fixed.
106
107         There are currently only 2 places where we create arrays with indexing type
108         ArrayClass: ArrayPrototype and RuntimeArray.  The fix in JSArray:;setLength()
109         takes care of ArrayPrototype.
110
111         RuntimeArray already checks for the setting of its length property, and will
112         throw a RangeError.  Hence, there's no change is needed for the RuntimeArray.
113         Instead, I added some test cases ensure that the check and throw behavior does
114         not change without notice.
115
116         * runtime/JSArray.cpp:
117         (JSC::JSArray::setLength):
118         * tests/stress/array-setLength-on-ArrayClass-with-large-length.js: Added.
119         (toString):
120         (assertEqual):
121         * tests/stress/array-setLength-on-ArrayClass-with-small-length.js: Added.
122         (toString):
123         (assertEqual):
124
125 2016-07-29  Keith Miller  <keith_miller@apple.com>
126
127         TypedArray super constructor has some incompatabilities
128         https://bugs.webkit.org/show_bug.cgi?id=160369
129
130         Reviewed by Filip Pizlo.
131
132         This patch fixes the length proprety of the TypedArray super constructor.
133         Additionally, the TypedArray super constructor should no longer be callable.
134
135         Also, this patch fixes the expected result of some test262 tests.
136
137         * runtime/JSTypedArrayViewConstructor.cpp:
138         (JSC::JSTypedArrayViewConstructor::finishCreation):
139         (JSC::constructTypedArrayView):
140         (JSC::JSTypedArrayViewConstructor::getCallData):
141         * tests/test262.yaml:
142
143 2016-07-29  Jonathan Bedard  <jbedard@apple.com>
144
145         Undefined Behavior in JSValue cast from NaN
146         https://bugs.webkit.org/show_bug.cgi?id=160322
147
148         Reviewed by Mark Lam.
149
150         JSValues can be constructed from doubles, and in some cases, are deliberately constructed with NaN values.
151
152         In circumstances where NaN is bound through the default JSValue constructor, however, an undefined conversion
153         to int32_t occurs.  While the subsequent if statement should fail and construct the JSValue through the explicit
154         double constructor, given that the deliberate use of NaN is fairly common, it seems that the jsNaN() function
155         should immediately call the explicit double constructor both for efficiency and to prevent inadvertent
156         suppressing of any other bugs which may be instantiating a JSValue with a NaN double.
157
158         * runtime/JSCJSValueInlines.h:
159         (JSC::jsNaN): Explicit double construction for NaN JSValues to avoid undefined behavior.
160
161 2016-07-29  Michael Saboff  <msaboff@apple.com>
162
163         Refactor DFG::Node::hasLocal() to accessesStack()
164         https://bugs.webkit.org/show_bug.cgi?id=160357
165
166         Reviewed by Filip Pizlo.
167
168         Refactoring in preparation for using register arguments for JavaScript calls.
169
170         Renamed Node::hasLocal() to Node::accessesStack() and changed all uses accordingly.
171         Also changed uses of Node::hasVariableAccessData() to accessesStack() where that
172         use guards stack operation logic associated with the Node's VariableAccessData.
173
174         The hasVariableAccessData() check now implies no more than the node has a
175         VariableAccessData and nothing about its use of that data to coordinate stack   
176         accesses.
177
178         * dfg/DFGGraph.cpp:
179         (JSC::DFG::Graph::dump):
180         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
181         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
182         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
183         * dfg/DFGMaximalFlushInsertionPhase.cpp:
184         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
185         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
186         * dfg/DFGNode.h:
187         (JSC::DFG::Node::containsMovHint):
188         (JSC::DFG::Node::accessesStack):
189         (JSC::DFG::Node::hasLocal): Deleted.
190         * dfg/DFGPredictionInjectionPhase.cpp:
191         (JSC::DFG::PredictionInjectionPhase::run):
192         * dfg/DFGValidate.cpp:
193
194 2016-07-29  Benjamin Poulain  <benjamin@webkit.org>
195
196         [JSC] Use the same data structures for DFG and Air Liveness Analysis
197         https://bugs.webkit.org/show_bug.cgi?id=160346
198
199         Reviewed by Geoffrey Garen.
200
201         In Air, we minimized memory accesses during liveness analysis
202         with a couple of tricks:
203         -Use a single Sparse Set ADT for the live value of each block.
204         -Manipulate compact positive indices instead of hashing values.
205
206         This patch brings the same ideas to DFG.
207
208         This patch still uses the same fixpoint algorithms.
209         The reason is Edge's KillStatus used by other phases. We cannot
210         use a block-boundary liveness algorithm and update KillStatus
211         simultaneously. It's something I'll probably revisit at some point.
212
213         * dfg/DFGAbstractInterpreterInlines.h:
214         (JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
215         (JSC::DFG::AbstractInterpreter<AbstractStateType>::dump):
216         * dfg/DFGBasicBlock.h:
217         * dfg/DFGGraph.h:
218         (JSC::DFG::Graph::maxNodeCount):
219         (JSC::DFG::Graph::nodeAt):
220         * dfg/DFGInPlaceAbstractState.cpp:
221         (JSC::DFG::setLiveValues):
222         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
223         * dfg/DFGLivenessAnalysisPhase.cpp:
224         (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase):
225         (JSC::DFG::LivenessAnalysisPhase::run):
226         (JSC::DFG::LivenessAnalysisPhase::processBlock):
227         (JSC::DFG::LivenessAnalysisPhase::addChildUse):
228         (JSC::DFG::LivenessAnalysisPhase::process): Deleted.
229
230 2016-07-29  Yusuke Suzuki  <utatane.tea@gmail.com>
231
232         Unreviewed, ByValInfo is only used in JIT enabled environments
233         https://bugs.webkit.org/show_bug.cgi?id=158908
234
235         * bytecode/CodeBlock.cpp:
236         (JSC::CodeBlock::stronglyVisitStrongReferences):
237
238 2016-07-28  Yusuke Suzuki  <utatane.tea@gmail.com>
239
240         JSC::Symbol should be hash-consed
241         https://bugs.webkit.org/show_bug.cgi?id=158908
242
243         Reviewed by Filip Pizlo.
244
245         Previously, SymbolImpls held by symbols represent identity of symbols.
246         When we check the equality between symbols, we need to load SymbolImpls of symbols and compare them.
247
248         This patch performs hash-consing onto the symbols. We cache symbols in per-VM's SymbolImpl-keyed WeakGCMap.
249         When creating a new symbol from SymbolImpl, we first query to this map and reuse the previously created symbol
250         if it is found. This ensures that one-on-one correspondence between SymbolImpl and symbol. So now, we can use
251         pointer-comparison to query the equality of symbols.
252
253         This change drops SymbolImpl loads when checking the equality. Furthermore, we can use DFG CheckCell to symbol
254         when we would like to ensure that the given value is the expected symbol. This cleans up GetByVal's symbol-keyd
255         caching. Then, we changed CheckIdent to CheckStringIdent since it only checks the string case now. The symbol
256         case is handled by CheckCell.
257
258         Additionally, this patch also cleans up Map / Set implementation since we can use the logic for JSCell to symbols.
259
260         The performance effects in the related benchmarks are the followings.
261
262                                                                baseline                   patch
263
264             bigswitch-indirect-symbol-or-undefined         85.6214+-1.0063     ^     63.0522+-0.8615        ^ definitely 1.3579x faster
265             bigswitch-indirect-symbol                      84.9653+-0.6258     ^     80.4900+-0.8008        ^ definitely 1.0556x faster
266             fold-put-by-val-with-symbol-to-multi-put-by-offset
267                                                             9.4396+-0.3726            9.2941+-0.3311          might be 1.0157x faster
268             inlined-put-by-val-with-symbol-transition
269                                                            49.5477+-0.2401     ?     49.7533+-0.3369        ?
270             get-by-val-with-symbol-self-or-proto           11.9740+-0.0798     ?     12.1706+-0.2723        ? might be 1.0164x slower
271             get-by-val-with-symbol-quadmorphic-check-structure-elimination-simple
272                                                             4.1364+-0.0841            4.0872+-0.0925          might be 1.0120x faster
273             put-by-val-with-symbol                         11.3709+-0.0223           11.3613+-0.0264
274             get-by-val-with-symbol-proto-or-self           11.8984+-0.0706     ?     11.9030+-0.0787        ?
275             polymorphic-put-by-val-with-symbol             31.4176+-0.0558           31.3825+-0.0447
276             implicit-bigswitch-indirect-symbol             61.3115+-0.6577     ^     58.0098+-0.1212        ^ definitely 1.0569x faster
277             get-by-val-with-symbol-bimorphic-check-structure-elimination-simple
278                                                             3.3139+-0.0565     ^      2.9947+-0.0732        ^ definitely 1.1066x faster
279             get-by-val-with-symbol-chain-from-try-block
280                                                             2.2316+-0.0179            2.2137+-0.0210
281             get-by-val-with-symbol-bimorphic-check-structure-elimination
282                                                            10.6031+-0.2216     ^     10.0939+-0.1977        ^ definitely 1.0504x faster
283             get-by-val-with-symbol-check-structure-elimination
284                                                             8.5576+-0.1521     ^      7.7107+-0.1308        ^ definitely 1.1098x faster
285             put-by-val-with-symbol-slightly-polymorphic
286                                                             3.1957+-0.0538     ^      2.9181+-0.0708        ^ definitely 1.0951x faster
287             put-by-val-with-symbol-replace-and-transition
288                                                            11.8253+-0.0757     ^     11.6590+-0.0351        ^ definitely 1.0143x faster
289
290             <geometric>                                    13.3911+-0.0527     ^     12.7376+-0.0457        ^ definitely 1.0513x faster
291
292         * bytecode/ByValInfo.h:
293         * bytecode/CodeBlock.cpp:
294         (JSC::CodeBlock::stronglyVisitStrongReferences):
295         * dfg/DFGAbstractInterpreterInlines.h:
296         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
297         * dfg/DFGByteCodeParser.cpp:
298         (JSC::DFG::ByteCodeParser::parseBlock):
299         * dfg/DFGClobberize.h:
300         (JSC::DFG::clobberize):
301         * dfg/DFGConstantFoldingPhase.cpp:
302         (JSC::DFG::ConstantFoldingPhase::foldConstants):
303         * dfg/DFGDoesGC.cpp:
304         (JSC::DFG::doesGC):
305         * dfg/DFGFixupPhase.cpp:
306         (JSC::DFG::FixupPhase::fixupNode):
307         * dfg/DFGNode.h:
308         (JSC::DFG::Node::hasUidOperand):
309         * dfg/DFGNodeType.h:
310         * dfg/DFGPredictionPropagationPhase.cpp:
311         * dfg/DFGSafeToExecute.h:
312         (JSC::DFG::safeToExecute):
313         * dfg/DFGSpeculativeJIT.cpp:
314         (JSC::DFG::SpeculativeJIT::compileSymbolEquality):
315         (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality):
316         (JSC::DFG::SpeculativeJIT::compileCheckStringIdent):
317         (JSC::DFG::SpeculativeJIT::extractStringImplFromBinarySymbols): Deleted.
318         (JSC::DFG::SpeculativeJIT::compileCheckIdent): Deleted.
319         (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality): Deleted.
320         * dfg/DFGSpeculativeJIT.h:
321         * dfg/DFGSpeculativeJIT32_64.cpp:
322         (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality):
323         (JSC::DFG::SpeculativeJIT::compile):
324         * dfg/DFGSpeculativeJIT64.cpp:
325         (JSC::DFG::SpeculativeJIT::compileSymbolUntypedEquality):
326         (JSC::DFG::SpeculativeJIT::compile):
327         * ftl/FTLAbstractHeapRepository.h:
328         * ftl/FTLCapabilities.cpp:
329         (JSC::FTL::canCompile):
330         * ftl/FTLLowerDFGToB3.cpp:
331         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
332         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
333         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
334         (JSC::FTL::DFG::LowerDFGToB3::compileCheckIdent): Deleted.
335         (JSC::FTL::DFG::LowerDFGToB3::lowSymbolUID): Deleted.
336         * jit/JIT.h:
337         * jit/JITOperations.cpp:
338         (JSC::tryGetByValOptimize):
339         * jit/JITPropertyAccess.cpp:
340         (JSC::JIT::emitGetByValWithCachedId):
341         (JSC::JIT::emitPutByValWithCachedId):
342         (JSC::JIT::emitByValIdentifierCheck):
343         (JSC::JIT::privateCompileGetByValWithCachedId):
344         (JSC::JIT::privateCompilePutByValWithCachedId):
345         (JSC::JIT::emitIdentifierCheck): Deleted.
346         * jit/JITPropertyAccess32_64.cpp:
347         (JSC::JIT::emitGetByValWithCachedId):
348         (JSC::JIT::emitPutByValWithCachedId):
349         * runtime/JSCJSValue.cpp:
350         (JSC::JSValue::dumpInContextAssumingStructure):
351         * runtime/JSCJSValueInlines.h:
352         (JSC::JSValue::equalSlowCaseInline):
353         (JSC::JSValue::strictEqualSlowCaseInline): Deleted.
354         * runtime/JSFunction.cpp:
355         (JSC::JSFunction::setFunctionName):
356         * runtime/MapData.h:
357         * runtime/MapDataInlines.h:
358         (JSC::JSIterator>::clear): Deleted.
359         (JSC::JSIterator>::find): Deleted.
360         (JSC::JSIterator>::add): Deleted.
361         (JSC::JSIterator>::remove): Deleted.
362         (JSC::JSIterator>::replaceAndPackBackingStore): Deleted.
363         * runtime/Symbol.cpp:
364         (JSC::Symbol::finishCreation):
365         (JSC::Symbol::create):
366         * runtime/Symbol.h:
367         * runtime/VM.cpp:
368         (JSC::VM::VM):
369         * runtime/VM.h:
370         * tests/stress/symbol-equality-over-gc.js: Added.
371         (shouldBe):
372         (test):
373
374 2016-07-28  Mark Lam  <mark.lam@apple.com>
375
376         ASSERTION FAILED in errorProtoFuncToString() when Error name is a single char string.
377         https://bugs.webkit.org/show_bug.cgi?id=160324
378         <rdar://problem/27389572>
379
380         Reviewed by Keith Miller.
381
382         The issue is that errorProtoFuncToString() was using jsNontrivialString() to
383         generate the error string even when the name string can be a single character
384         string.  This is incorrect.  We should be using jsString() instead.
385
386         * runtime/ErrorPrototype.cpp:
387         (JSC::errorProtoFuncToString):
388         * tests/stress/errors-with-simple-names-or-messages-should-not-crash-toString.js: Added.
389
390 2016-07-28  Michael Saboff  <msaboff@apple.com>
391
392         ARM64: Fused left shift with a right shift can create NaNs from integers
393         https://bugs.webkit.org/show_bug.cgi?id=160329
394
395         Reviewed by Geoffrey Garen.
396
397         When we fuse a left shift and a right shift of integers where the shift amounts
398         are the same and the size of the quantity being shifted is 8 bits, we rightly
399         generate a sign extend byte instruction.  On ARM64, we were sign extending
400         to a 64 bit quantity, when we really wanted to sign extend to a 32 bit quantity.
401
402         Checking the ARM64 marco assembler and we were extending to 64 bits for all
403         four combinations of zero / sign and 8 / 16 bits.
404         
405         * assembler/MacroAssemblerARM64.h:
406         (JSC::MacroAssemblerARM64::zeroExtend16To32):
407         (JSC::MacroAssemblerARM64::signExtend16To32):
408         (JSC::MacroAssemblerARM64::zeroExtend8To32):
409         (JSC::MacroAssemblerARM64::signExtend8To32):
410         * tests/stress/regress-160329.js: New test added.
411         (narrow):
412
413 2016-07-28  Mark Lam  <mark.lam@apple.com>
414
415         StringView should have an explicit m_is8Bit field.
416         https://bugs.webkit.org/show_bug.cgi?id=160282
417         <rdar://problem/27327943>
418
419         Reviewed by Benjamin Poulain.
420
421         * tests/stress/string-joining-long-strings-should-not-crash.js: Added.
422         (catch):
423
424 2016-07-28  Csaba Osztrogonác  <ossy@webkit.org>
425
426         [ARM] Typo fix after r121885
427         https://bugs.webkit.org/show_bug.cgi?id=160288
428
429         Reviewed by Zoltan Herczeg.
430
431         * assembler/MacroAssemblerARM.h:
432         (JSC::MacroAssemblerARM::maxJumpReplacementSize):
433
434 2016-07-28  Csaba Osztrogonác  <ossy@webkit.org>
435
436         64-bit alignment check isn't necessary in ARMAssembler::prepareExecutableCopy after r202214
437         https://bugs.webkit.org/show_bug.cgi?id=159711
438
439         Reviewed by Mark Lam.
440
441         * assembler/ARMAssembler.cpp:
442         (JSC::ARMAssembler::prepareExecutableCopy):
443
444 2016-07-27  Benjamin Poulain  <bpoulain@apple.com>
445
446         [JSC] Remove some unused code from FTL
447         https://bugs.webkit.org/show_bug.cgi?id=160285
448
449         Reviewed by Mark Lam.
450
451         All the liveness and swapping is done inside B3,
452         this code is no longer needed.
453
454         * dfg/DFGEdge.h:
455         (JSC::DFG::Edge::doesNotKill): Deleted.
456         * ftl/FTLLowerDFGToB3.cpp:
457         (JSC::FTL::DFG::LowerDFGToB3::doesKill): Deleted.
458
459 2016-07-27  Benjamin Poulain  <bpoulain@apple.com>
460
461         [JSC] DFG::Node should not have its own allocator
462         https://bugs.webkit.org/show_bug.cgi?id=160098
463
464         Reviewed by Geoffrey Garen.
465
466         We need some design changes for DFG::Node:
467         -Accessing the index must be fast. B3 uses indices for sets
468          and maps, it is a lot faster than hashing pointers.
469         -We should be able to subclass DFG::Node to specialize it.
470
471         * CMakeLists.txt:
472         * JavaScriptCore.xcodeproj/project.pbxproj:
473         * dfg/DFGAllocator.h: Removed.
474         (JSC::DFG::Allocator::Region::size): Deleted.
475         (JSC::DFG::Allocator::Region::headerSize): Deleted.
476         (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): Deleted.
477         (JSC::DFG::Allocator::Region::data): Deleted.
478         (JSC::DFG::Allocator::Region::isInThisRegion): Deleted.
479         (JSC::DFG::Allocator::Region::regionFor): Deleted.
480         (JSC::DFG::Allocator<T>::Allocator): Deleted.
481         (JSC::DFG::Allocator<T>::~Allocator): Deleted.
482         (JSC::DFG::Allocator<T>::allocate): Deleted.
483         (JSC::DFG::Allocator<T>::free): Deleted.
484         (JSC::DFG::Allocator<T>::freeAll): Deleted.
485         (JSC::DFG::Allocator<T>::reset): Deleted.
486         (JSC::DFG::Allocator<T>::indexOf): Deleted.
487         (JSC::DFG::Allocator<T>::allocatorOf): Deleted.
488         (JSC::DFG::Allocator<T>::bumpAllocate): Deleted.
489         (JSC::DFG::Allocator<T>::freeListAllocate): Deleted.
490         (JSC::DFG::Allocator<T>::allocateSlow): Deleted.
491         (JSC::DFG::Allocator<T>::freeRegionsStartingAt): Deleted.
492         (JSC::DFG::Allocator<T>::startBumpingIn): Deleted.
493         * dfg/DFGByteCodeParser.cpp:
494         (JSC::DFG::ByteCodeParser::addToGraph):
495         * dfg/DFGCPSRethreadingPhase.cpp:
496         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
497         (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
498         * dfg/DFGCleanUpPhase.cpp:
499         (JSC::DFG::CleanUpPhase::run):
500         * dfg/DFGConstantFoldingPhase.cpp:
501         (JSC::DFG::ConstantFoldingPhase::run):
502         * dfg/DFGConstantHoistingPhase.cpp:
503         * dfg/DFGDCEPhase.cpp:
504         (JSC::DFG::DCEPhase::fixupBlock):
505         * dfg/DFGDriver.cpp:
506         (JSC::DFG::compileImpl):
507         * dfg/DFGGraph.cpp:
508         (JSC::DFG::Graph::Graph):
509         (JSC::DFG::Graph::deleteNode):
510         (JSC::DFG::Graph::killBlockAndItsContents):
511         (JSC::DFG::Graph::~Graph): Deleted.
512         * dfg/DFGGraph.h:
513         (JSC::DFG::Graph::addNode):
514         * dfg/DFGLICMPhase.cpp:
515         (JSC::DFG::LICMPhase::attemptHoist):
516         * dfg/DFGLongLivedState.cpp: Removed.
517         (JSC::DFG::LongLivedState::LongLivedState): Deleted.
518         (JSC::DFG::LongLivedState::~LongLivedState): Deleted.
519         (JSC::DFG::LongLivedState::shrinkToFit): Deleted.
520         * dfg/DFGLongLivedState.h: Removed.
521         * dfg/DFGNode.cpp:
522         (JSC::DFG::Node::index): Deleted.
523         * dfg/DFGNode.h:
524         (JSC::DFG::Node::index):
525         * dfg/DFGNodeAllocator.h: Removed.
526         (operator new ): Deleted.
527         * dfg/DFGObjectAllocationSinkingPhase.cpp:
528         * dfg/DFGPlan.cpp:
529         (JSC::DFG::Plan::compileInThread):
530         (JSC::DFG::Plan::compileInThreadImpl):
531         * dfg/DFGPlan.h:
532         * dfg/DFGSSAConversionPhase.cpp:
533         (JSC::DFG::SSAConversionPhase::run):
534         * dfg/DFGWorklist.cpp:
535         (JSC::DFG::Worklist::runThread):
536         * runtime/VM.cpp:
537         (JSC::VM::VM): Deleted.
538         * runtime/VM.h:
539
540 2016-07-27  Benjamin Poulain  <bpoulain@apple.com>
541
542         [JSC] Fix a bunch of use-after-free of DFG::Node
543         https://bugs.webkit.org/show_bug.cgi?id=160228
544
545         Reviewed by Mark Lam.
546
547         FTL had a few places where we use a node after it has been
548         deleted. The dangling pointers come from the SSA liveness information
549         kept on the basic blocks.
550
551         This patch fixes the issues I could find and adds liveness invalidation
552         to help finding dependencies like these.
553
554         * dfg/DFGBasicBlock.h:
555         (JSC::DFG::BasicBlock::SSAData::invalidate):
556
557         * dfg/DFGConstantFoldingPhase.cpp:
558         (JSC::DFG::ConstantFoldingPhase::run):
559         Constant folding phase was deleting nodes in the loop over basic blocks.
560         The problem is the deleted nodes can be referenced by other blocks.
561         When the abstract interpreter was manipulating the abstract values of those
562         it was doing so on the dead nodes.
563
564         * dfg/DFGConstantHoistingPhase.cpp:
565         Just invalidation. Nothing wrong here since the useless nodes were
566         kept live while iterating the blocks.
567
568         * dfg/DFGGraph.cpp:
569         (JSC::DFG::Graph::killBlockAndItsContents):
570         (JSC::DFG::Graph::killUnreachableBlocks):
571         (JSC::DFG::Graph::invalidateNodeLiveness):
572
573         * dfg/DFGGraph.h:
574         * dfg/DFGPlan.cpp:
575         (JSC::DFG::Plan::compileInThreadImpl):
576         We had a lot of use-after-free in LCIM because we were using the stale
577         live nodes deleted by previous phases.
578
579 2016-07-27  Keith Miller  <keith_miller@apple.com>
580
581         concatAppendOne should allocate using the indexing type of the array if it cannot merge
582         https://bugs.webkit.org/show_bug.cgi?id=160261
583         <rdar://problem/27530122>
584
585         Reviewed by Mark Lam.
586
587         Before, if we could not merge the indexing types for copying, we would allocate the
588         the array as ArrayWithUndecided. Instead, we should allocate an array with the original
589         array's indexing type.
590
591         * runtime/ArrayPrototype.cpp:
592         (JSC::concatAppendOne):
593         * tests/stress/concat-append-one-with-sparse-array.js: Added.
594
595 2016-07-27  Saam Barati  <sbarati@apple.com>
596
597         We don't optimize for-in properly in baseline JIT (maybe other JITs too) with an object with symbols
598         https://bugs.webkit.org/show_bug.cgi?id=160211
599         <rdar://problem/27572612>
600
601         Reviewed by Geoffrey Garen.
602
603         The fast for-in iteration mode assumes all inline/out-of-line properties
604         can be iterated in linear order. This is not true if we have Symbols
605         because Symbols should not be iterated by for-in.
606
607         * runtime/Structure.cpp:
608         (JSC::Structure::add):
609         * tests/stress/symbol-should-not-break-for-in.js: Added.
610         (assert):
611         (foo):
612
613 2016-07-27  Mark Lam  <mark.lam@apple.com>
614
615         The second argument for Function.prototype.apply should be array-like or null/undefined.
616         https://bugs.webkit.org/show_bug.cgi?id=160212
617         <rdar://problem/27328525>
618
619         Reviewed by Filip Pizlo.
620
621         The spec for Function.prototype.apply says its second argument can only be null,
622         undefined, or must be array-like.  See
623         https://tc39.github.io/ecma262/#sec-function.prototype.apply and
624         https://tc39.github.io/ecma262/#sec-createlistfromarraylike.
625
626         Our previous implementation was not handling this correctly for SymbolType.
627         This is now fixed.
628
629         * interpreter/Interpreter.cpp:
630         (JSC::sizeOfVarargs):
631         * tests/stress/apply-second-argument-must-be-array-like.js: Added.
632
633 2016-07-27  Saam Barati  <sbarati@apple.com>
634
635         MathICs should be able to emit only a jump along the inline path when they don't have any type data
636         https://bugs.webkit.org/show_bug.cgi?id=160110
637
638         Reviewed by Mark Lam.
639
640         This patch allows for MathIC fast-path generation to be delayed.
641         We delay when we don't see any observed type information for
642         the lhs/rhs operand, which implies that the MathIC has never
643         executed. This is profitable for two main reasons:
644         1. If the math operation never executes, we emit much less code.
645         2. Once we get type information for the lhs/rhs, we can emit better code.
646
647         To implement this, we just emit a jump to the slow path call
648         that will repatch on first execution.
649
650         New data for add:
651                    |   JetStream  |  Unity 3D  |
652              ------| -------------|--------------
653               Old  |   148 bytes  |  143 bytes |
654              ------| -------------|--------------
655               New  |   116  bytes |  113 bytes |
656              ------------------------------------
657
658         New data for mul:
659                    |   JetStream  |  Unity 3D  |
660              ------| -------------|--------------
661               Old  |   210 bytes  |  185 bytes |
662              ------| -------------|--------------
663               New  |   170  bytes |  137 bytes |
664              ------------------------------------
665
666         * jit/JITAddGenerator.cpp:
667         (JSC::JITAddGenerator::generateInline):
668         * jit/JITAddGenerator.h:
669         (JSC::JITAddGenerator::isLeftOperandValidConstant):
670         (JSC::JITAddGenerator::isRightOperandValidConstant):
671         (JSC::JITAddGenerator::arithProfile):
672         * jit/JITMathIC.h:
673         (JSC::JITMathIC::generateInline):
674         (JSC::JITMathIC::generateOutOfLine):
675         (JSC::JITMathIC::finalizeInlineCode):
676         * jit/JITMathICInlineResult.h:
677         * jit/JITMulGenerator.cpp:
678         (JSC::JITMulGenerator::generateInline):
679         * jit/JITMulGenerator.h:
680         (JSC::JITMulGenerator::isLeftOperandValidConstant):
681         (JSC::JITMulGenerator::isRightOperandValidConstant):
682         (JSC::JITMulGenerator::arithProfile):
683         * jit/JITOperations.cpp:
684
685 2016-07-26  Saam Barati  <sbarati@apple.com>
686
687         rollout r203666
688         https://bugs.webkit.org/show_bug.cgi?id=160226
689
690         Unreviewed rollout.
691
692         * b3/B3BasicBlock.h:
693         (JSC::B3::BasicBlock::successorBlock):
694         * b3/B3LowerToAir.cpp:
695         (JSC::B3::Air::LowerToAir::createGenericCompare):
696         * b3/B3LowerToAir.h:
697         * b3/air/AirArg.cpp:
698         (JSC::B3::Air::Arg::isRepresentableAs):
699         (JSC::B3::Air::Arg::usesTmp):
700         * b3/air/AirArg.h:
701         (JSC::B3::Air::Arg::isRepresentableAs):
702         (JSC::B3::Air::Arg::asNumber):
703         (JSC::B3::Air::Arg::castToType): Deleted.
704         * b3/air/AirCode.h:
705         (JSC::B3::Air::Code::size):
706         (JSC::B3::Air::Code::at):
707         * b3/air/AirOpcode.opcodes:
708         * b3/air/AirValidate.h:
709         * b3/air/opcode_generator.rb:
710         * b3/testb3.cpp:
711         (JSC::B3::compileAndRun):
712         (JSC::B3::testSomeEarlyRegister):
713         (JSC::B3::zero):
714         (JSC::B3::run):
715         (JSC::B3::lowerToAirForTesting): Deleted.
716         (JSC::B3::testBranchBitAndImmFusion): Deleted.
717
718 2016-07-26  Caitlin Potter  <caitp@igalia.com>
719
720         [JSC] Object.getOwnPropertyDescriptors should not add undefined props to result
721         https://bugs.webkit.org/show_bug.cgi?id=159409
722
723         Reviewed by Geoffrey Garen.
724
725         * runtime/ObjectConstructor.cpp:
726         (JSC::objectConstructorGetOwnPropertyDescriptors):
727         * tests/es6.yaml:
728         * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js:
729         (testPropertiesIndexedSetterOnPrototypeThrows.set get var): Deleted.
730         (testPropertiesIndexedSetterOnPrototypeThrows): Deleted.
731         * tests/stress/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js: Renamed from Source/JavaScriptCore/tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js.
732         * tests/stress/Object_static_methods_Object.getOwnPropertyDescriptors.js: Renamed from Source/JavaScriptCore/tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js.
733
734 2016-07-26  Mark Lam  <mark.lam@apple.com>
735
736         Remove unused DEBUG_WITH_BREAKPOINT configuration.
737         https://bugs.webkit.org/show_bug.cgi?id=160203
738
739         Reviewed by Keith Miller.
740
741         * bytecompiler/BytecodeGenerator.cpp:
742         (JSC::BytecodeGenerator::emitDebugHook):
743
744 2016-07-25  Benjamin Poulain  <benjamin@webkit.org>
745
746         Unreviewed, rolling out r203703.
747
748         It breaks some internal tests
749
750         Reverted changeset:
751
752         "[JSC] DFG::Node should not have its own allocator"
753         https://bugs.webkit.org/show_bug.cgi?id=160098
754         http://trac.webkit.org/changeset/203703
755
756 2016-07-25  Benjamin Poulain  <bpoulain@apple.com>
757
758         [JSC] DFG::Node should not have its own allocator
759         https://bugs.webkit.org/show_bug.cgi?id=160098
760
761         Reviewed by Geoffrey Garen.
762
763         We need some design changes for DFG::Node:
764         -Accessing the index must be fast. B3 uses indices for sets
765          and maps, it is a lot faster than hashing pointers.
766         -We should be able to subclass DFG::Node to specialize it.
767
768         * CMakeLists.txt:
769         * JavaScriptCore.xcodeproj/project.pbxproj:
770         * dfg/DFGAllocator.h: Removed.
771         (JSC::DFG::Allocator::Region::size): Deleted.
772         (JSC::DFG::Allocator::Region::headerSize): Deleted.
773         (JSC::DFG::Allocator::Region::numberOfThingsPerRegion): Deleted.
774         (JSC::DFG::Allocator::Region::data): Deleted.
775         (JSC::DFG::Allocator::Region::isInThisRegion): Deleted.
776         (JSC::DFG::Allocator::Region::regionFor): Deleted.
777         (JSC::DFG::Allocator<T>::Allocator): Deleted.
778         (JSC::DFG::Allocator<T>::~Allocator): Deleted.
779         (JSC::DFG::Allocator<T>::allocate): Deleted.
780         (JSC::DFG::Allocator<T>::free): Deleted.
781         (JSC::DFG::Allocator<T>::freeAll): Deleted.
782         (JSC::DFG::Allocator<T>::reset): Deleted.
783         (JSC::DFG::Allocator<T>::indexOf): Deleted.
784         (JSC::DFG::Allocator<T>::allocatorOf): Deleted.
785         (JSC::DFG::Allocator<T>::bumpAllocate): Deleted.
786         (JSC::DFG::Allocator<T>::freeListAllocate): Deleted.
787         (JSC::DFG::Allocator<T>::allocateSlow): Deleted.
788         (JSC::DFG::Allocator<T>::freeRegionsStartingAt): Deleted.
789         (JSC::DFG::Allocator<T>::startBumpingIn): Deleted.
790         * dfg/DFGByteCodeParser.cpp:
791         (JSC::DFG::ByteCodeParser::addToGraph):
792         * dfg/DFGCPSRethreadingPhase.cpp:
793         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
794         (JSC::DFG::CPSRethreadingPhase::addPhiSilently):
795         * dfg/DFGCleanUpPhase.cpp:
796         (JSC::DFG::CleanUpPhase::run):
797         * dfg/DFGConstantFoldingPhase.cpp:
798         (JSC::DFG::ConstantFoldingPhase::run):
799         * dfg/DFGConstantHoistingPhase.cpp:
800         * dfg/DFGDCEPhase.cpp:
801         (JSC::DFG::DCEPhase::fixupBlock):
802         * dfg/DFGDriver.cpp:
803         (JSC::DFG::compileImpl):
804         * dfg/DFGGraph.cpp:
805         (JSC::DFG::Graph::Graph):
806         (JSC::DFG::Graph::deleteNode):
807         (JSC::DFG::Graph::killBlockAndItsContents):
808         (JSC::DFG::Graph::~Graph): Deleted.
809         * dfg/DFGGraph.h:
810         (JSC::DFG::Graph::addNode):
811         * dfg/DFGLICMPhase.cpp:
812         (JSC::DFG::LICMPhase::attemptHoist):
813         * dfg/DFGLongLivedState.cpp: Removed.
814         (JSC::DFG::LongLivedState::LongLivedState): Deleted.
815         (JSC::DFG::LongLivedState::~LongLivedState): Deleted.
816         (JSC::DFG::LongLivedState::shrinkToFit): Deleted.
817         * dfg/DFGLongLivedState.h: Removed.
818         * dfg/DFGNode.cpp:
819         (JSC::DFG::Node::index): Deleted.
820         * dfg/DFGNode.h:
821         (JSC::DFG::Node::index):
822         * dfg/DFGNodeAllocator.h: Removed.
823         (operator new ): Deleted.
824         * dfg/DFGObjectAllocationSinkingPhase.cpp:
825         * dfg/DFGPlan.cpp:
826         (JSC::DFG::Plan::compileInThread):
827         (JSC::DFG::Plan::compileInThreadImpl):
828         * dfg/DFGPlan.h:
829         * dfg/DFGSSAConversionPhase.cpp:
830         (JSC::DFG::SSAConversionPhase::run):
831         * dfg/DFGWorklist.cpp:
832         (JSC::DFG::Worklist::runThread):
833         * runtime/VM.cpp:
834         (JSC::VM::VM): Deleted.
835         * runtime/VM.h:
836
837 2016-07-25  Filip Pizlo  <fpizlo@apple.com>
838
839         AssemblyHelpers should own all of the cell allocation methods
840         https://bugs.webkit.org/show_bug.cgi?id=160171
841
842         Reviewed by Saam Barati.
843         
844         Prior to this change we had some code in DFGSpeculativeJIT.h and some code in JIT.h that
845         did cell allocation.
846         
847         This change moves all of that code into AssemblyHelpers.h.
848
849         * dfg/DFGSpeculativeJIT.h:
850         (JSC::DFG::SpeculativeJIT::emitAllocateJSCell):
851         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
852         (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
853         (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
854         (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
855         * jit/AssemblyHelpers.h:
856         (JSC::AssemblyHelpers::emitAllocate):
857         (JSC::AssemblyHelpers::emitAllocateJSCell):
858         (JSC::AssemblyHelpers::emitAllocateJSObject):
859         (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
860         (JSC::AssemblyHelpers::emitAllocateVariableSized):
861         (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
862         (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
863         * jit/JIT.h:
864         * jit/JITInlines.h:
865         (JSC::JIT::isOperandConstantChar):
866         (JSC::JIT::emitValueProfilingSite):
867         (JSC::JIT::emitAllocateJSObject): Deleted.
868         * jit/JITOpcodes.cpp:
869         (JSC::JIT::emit_op_new_object):
870         (JSC::JIT::emit_op_create_this):
871         * jit/JITOpcodes32_64.cpp:
872         (JSC::JIT::emit_op_new_object):
873         (JSC::JIT::emit_op_create_this):
874
875 2016-07-25  Saam Barati  <sbarati@apple.com>
876
877         MathICs should be able to take and dump stats about code size
878         https://bugs.webkit.org/show_bug.cgi?id=160148
879
880         Reviewed by Filip Pizlo.
881
882         This will make testing changes on MathIC going forward much easier.
883         We will be able to easily see if modifications to MathIC will lead
884         to us generating smaller code. We now only dump average size when we
885         regenerate any MathIC. This works out for large tests/pages, but is not
886         great for testing small programs. We can add more dump points later if
887         we find that we want to dump stats while running small small programs.
888
889         * bytecode/CodeBlock.cpp:
890         (JSC::CodeBlock::jitSoon):
891         (JSC::CodeBlock::dumpMathICStats):
892         * bytecode/CodeBlock.h:
893         (JSC::CodeBlock::isStrictMode):
894         (JSC::CodeBlock::ecmaMode):
895         * dfg/DFGSpeculativeJIT.cpp:
896         (JSC::DFG::SpeculativeJIT::compileMathIC):
897         * ftl/FTLLowerDFGToB3.cpp:
898         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
899         * jit/JITArithmetic.cpp:
900         (JSC::JIT::emitMathICFast):
901         (JSC::JIT::emitMathICSlow):
902         * jit/JITMathIC.h:
903         (JSC::JITMathIC::finalizeInlineCode):
904         (JSC::JITMathIC::codeSize):
905         * jit/JITOperations.cpp:
906
907 2016-07-25  Saam Barati  <sbarati@apple.com>
908
909         op_mul/ArithMul(Untyped,Untyped) should be an IC
910         https://bugs.webkit.org/show_bug.cgi?id=160108
911
912         Reviewed by Mark Lam.
913
914         This patch makes Mul a type based IC in much the same way that we made
915         Add a type-based IC. I implemented Mul in the same way. I abstracted the
916         implementation of the Add IC in the various JITs to allow for it to
917         work over arbitrary IC snippets. This will make adding Div/Sub/Pow in the
918         future easy. This patch also adds a new boolean argument to the various
919         snippet generateFastPath() methods to indicate if we should emit result profiling.
920         I added this because we want this profiling to be emitted for Mul in
921         the baseline, but not in the DFG. We used to indicate this through passing
922         in a nullptr for the ArithProfile, but we no longer do that in the upper
923         JIT tiers. So we are passing an explicit request from the JIT tier about
924         whether or not it's worth it for the IC to emit profiling.
925
926         We now emit much less code for Mul. Here is some data on the average
927         Mul snippet/IC size:
928
929                    |   JetStream  |  Unity 3D  |
930              ------| -------------|--------------
931               Old  |  ~280 bytes  | ~280 bytes |
932              ------| -------------|--------------
933               New  |   210  bytes |  185 bytes |
934              ------------------------------------
935
936         * bytecode/CodeBlock.cpp:
937         (JSC::CodeBlock::addJITAddIC):
938         (JSC::CodeBlock::addJITMulIC):
939         (JSC::CodeBlock::findStubInfo):
940         * bytecode/CodeBlock.h:
941         (JSC::CodeBlock::stubInfoBegin):
942         (JSC::CodeBlock::stubInfoEnd):
943         * dfg/DFGSpeculativeJIT.cpp:
944         (JSC::DFG::GPRTemporary::adopt):
945         (JSC::DFG::FPRTemporary::FPRTemporary):
946         (JSC::DFG::SpeculativeJIT::compileValueAdd):
947         (JSC::DFG::SpeculativeJIT::compileMathIC):
948         (JSC::DFG::SpeculativeJIT::compileArithMul):
949         * dfg/DFGSpeculativeJIT.h:
950         (JSC::DFG::SpeculativeJIT::callOperation):
951         (JSC::DFG::GPRTemporary::GPRTemporary):
952         (JSC::DFG::GPRTemporary::operator=):
953         (JSC::DFG::FPRTemporary::~FPRTemporary):
954         (JSC::DFG::FPRTemporary::fpr):
955         * ftl/FTLLowerDFGToB3.cpp:
956         (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
957         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
958         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
959         (JSC::FTL::DFG::LowerDFGToB3::compileArithMul):
960         * jit/JIT.h:
961         (JSC::JIT::getSlowCase):
962         * jit/JITAddGenerator.cpp:
963         (JSC::JITAddGenerator::generateInline):
964         (JSC::JITAddGenerator::generateFastPath):
965         * jit/JITAddGenerator.h:
966         (JSC::JITAddGenerator::JITAddGenerator):
967         (JSC::JITAddGenerator::isLeftOperandValidConstant):
968         (JSC::JITAddGenerator::isRightOperandValidConstant):
969         * jit/JITArithmetic.cpp:
970         (JSC::JIT::emit_op_add):
971         (JSC::JIT::emitSlow_op_add):
972         (JSC::JIT::emitMathICFast):
973         (JSC::JIT::emitMathICSlow):
974         (JSC::JIT::emit_op_mul):
975         (JSC::JIT::emitSlow_op_mul):
976         (JSC::JIT::emit_op_sub):
977         * jit/JITInlines.h:
978         (JSC::JIT::callOperation):
979         * jit/JITMathIC.h:
980         (JSC::JITMathIC::slowPathStartLocation):
981         (JSC::JITMathIC::slowPathCallLocation):
982         (JSC::JITMathIC::isLeftOperandValidConstant):
983         (JSC::JITMathIC::isRightOperandValidConstant):
984         (JSC::JITMathIC::generateInline):
985         (JSC::JITMathIC::generateOutOfLine):
986         * jit/JITMathICForwards.h:
987         * jit/JITMulGenerator.cpp:
988         (JSC::JITMulGenerator::generateInline):
989         (JSC::JITMulGenerator::generateFastPath):
990         * jit/JITMulGenerator.h:
991         (JSC::JITMulGenerator::JITMulGenerator):
992         (JSC::JITMulGenerator::isLeftOperandValidConstant):
993         (JSC::JITMulGenerator::isRightOperandValidConstant):
994         (JSC::JITMulGenerator::didEmitFastPath): Deleted.
995         (JSC::JITMulGenerator::endJumpList): Deleted.
996         (JSC::JITMulGenerator::slowPathJumpList): Deleted.
997         * jit/JITOperations.cpp:
998         * jit/JITOperations.h:
999
1000 2016-07-25  Darin Adler  <darin@apple.com>
1001
1002         Speed up make process slightly by improving "list of files" idiom
1003         https://bugs.webkit.org/show_bug.cgi?id=160164
1004
1005         Reviewed by Mark Lam.
1006
1007         * DerivedSources.make: Change rules that build lists of files to only run when
1008         DerivedSources.make has been modified since the last time they were run. Since the
1009         list of files are inside this file, this is safe, and this is faster than always
1010         comparing and regenerating the file containing the list of files each time.
1011
1012 2016-07-24  Youenn Fablet  <youenn@apple.com>
1013
1014         [Fetch API] Request should be created with any HeadersInit data
1015         https://bugs.webkit.org/show_bug.cgi?id=159672
1016
1017         Reviewed by Sam Weinig.
1018
1019         * Scripts/builtins/builtins_generator.py:
1020         (WK_lcfirst): Synchronized with CodeGenerator.pm version.
1021
1022 2016-07-24  Filip Pizlo  <fpizlo@apple.com>
1023
1024         B3 should support multiple entrypoints
1025         https://bugs.webkit.org/show_bug.cgi?id=159391
1026
1027         Reviewed by Saam Barati.
1028         
1029         This teaches B3 how to compile procedures with multiple entrypoints in the best way ever.
1030         
1031         Multiple entrypoints are useful. We could use them to reduce the cost of compiling OSR
1032         entrypoints. We could use them to implement better try/catch.
1033         
1034         Multiple entrypoints are hard to support. All of the code that assumed that the root block
1035         is the entrypoint would have to be changed. Transformations like moveConstants() would have
1036         to do crazy things if the existence of multiple entrypoints prevented it from finding a
1037         single common dominator.
1038         
1039         Therefore, we want to add multiple entrypoints without actually teaching the compiler that
1040         there is such a thing. That's sort of what this change does.
1041         
1042         This adds a new opcode to both B3 and Air called EntrySwitch. It's a terminal that takes
1043         one or more successors and no value children. The number of successors must match
1044         Procedure::numEntrypoints(), which could be arbitrarily large. The semantics of EntrySwitch
1045         are:
1046         
1047         - Each of the entrypoints sets a hidden Entry variable to that entrypoint's index and jumps
1048           to the procedure's root block.
1049         
1050         - An EntrySwitch is a switch statement over this hidden Entry variable.
1051         
1052         The way that we actually implement this is that Air has a very late phase - after all
1053         register and stack layout - that clones all code where the Entry variable is live; i.e all
1054         code in the closure over predecessors of all blocks that do EntrySwitch.
1055         
1056         Usually, you would use this by creating an EntrySwitch in the root block, but you don't
1057         have to do that. Just remember that the code before EntrySwitch gets cloned for each
1058         entrypoint. We allow cloning of an arbitrarily large amount of code because restricting it,
1059         and so restricing the placement of EntrySwitches, would be unelegant. It would be hard to
1060         preserve this invariant. For example we wouldn't be able to lower any value before an
1061         EntrySwitch to a control flow diamond.
1062         
1063         This patch gives us an easy-to-use way to use B3 to compile code with multiple entrypoints.
1064         Inside the compiler, only code that runs very late in Air has to know about this feature.
1065         We get the best of both worlds!
1066         
1067         Also, I finally got rid of the requirement that you explicitly cast BasicBlock* to
1068         FrequentedBlock. I can no longer remember why I thought that was a good idea. Removing it
1069         doesn't cause any problems and it makes code easier to write.
1070
1071         * CMakeLists.txt:
1072         * JavaScriptCore.xcodeproj/project.pbxproj:
1073         * b3/B3BasicBlockUtils.h:
1074         (JSC::B3::updatePredecessorsAfter):
1075         (JSC::B3::clearPredecessors):
1076         (JSC::B3::recomputePredecessors):
1077         * b3/B3FrequencyClass.h:
1078         (JSC::B3::maxFrequency):
1079         * b3/B3Generate.h:
1080         * b3/B3LowerToAir.cpp:
1081         (JSC::B3::Air::LowerToAir::lower):
1082         * b3/B3MoveConstants.cpp:
1083         * b3/B3Opcode.cpp:
1084         (WTF::printInternal):
1085         * b3/B3Opcode.h:
1086         * b3/B3Procedure.cpp:
1087         (JSC::B3::Procedure::isFastConstant):
1088         (JSC::B3::Procedure::entrypointLabel):
1089         (JSC::B3::Procedure::addDataSection):
1090         * b3/B3Procedure.h:
1091         (JSC::B3::Procedure::numEntrypoints):
1092         (JSC::B3::Procedure::setNumEntrypoints):
1093         (JSC::B3::Procedure::setLastPhaseName):
1094         * b3/B3Validate.cpp:
1095         * b3/B3Value.cpp:
1096         (JSC::B3::Value::effects):
1097         (JSC::B3::Value::typeFor):
1098         * b3/B3Value.h:
1099         * b3/air/AirCode.cpp:
1100         (JSC::B3::Air::Code::cCallSpecial):
1101         (JSC::B3::Air::Code::isEntrypoint):
1102         (JSC::B3::Air::Code::resetReachability):
1103         (JSC::B3::Air::Code::dump):
1104         * b3/air/AirCode.h:
1105         (JSC::B3::Air::Code::setFrameSize):
1106         (JSC::B3::Air::Code::numEntrypoints):
1107         (JSC::B3::Air::Code::entrypoints):
1108         (JSC::B3::Air::Code::entrypoint):
1109         (JSC::B3::Air::Code::setEntrypoints):
1110         (JSC::B3::Air::Code::entrypointLabel):
1111         (JSC::B3::Air::Code::setEntrypointLabels):
1112         (JSC::B3::Air::Code::calleeSaveRegisters):
1113         * b3/air/AirCustom.h:
1114         (JSC::B3::Air::PatchCustom::isTerminal):
1115         (JSC::B3::Air::PatchCustom::hasNonArgEffects):
1116         (JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
1117         (JSC::B3::Air::PatchCustom::generate):
1118         (JSC::B3::Air::CommonCustomBase::hasNonArgEffects):
1119         (JSC::B3::Air::CCallCustom::forEachArg):
1120         (JSC::B3::Air::ColdCCallCustom::forEachArg):
1121         (JSC::B3::Air::ShuffleCustom::forEachArg):
1122         (JSC::B3::Air::EntrySwitchCustom::forEachArg):
1123         (JSC::B3::Air::EntrySwitchCustom::isValidFormStatic):
1124         (JSC::B3::Air::EntrySwitchCustom::isValidForm):
1125         (JSC::B3::Air::EntrySwitchCustom::admitsStack):
1126         (JSC::B3::Air::EntrySwitchCustom::isTerminal):
1127         (JSC::B3::Air::EntrySwitchCustom::hasNonArgNonControlEffects):
1128         (JSC::B3::Air::EntrySwitchCustom::generate):
1129         * b3/air/AirGenerate.cpp:
1130         (JSC::B3::Air::prepareForGeneration):
1131         (JSC::B3::Air::generate):
1132         * b3/air/AirLowerEntrySwitch.cpp: Added.
1133         (JSC::B3::Air::lowerEntrySwitch):
1134         * b3/air/AirLowerEntrySwitch.h: Added.
1135         * b3/air/AirOpcode.opcodes:
1136         * b3/air/AirOptimizeBlockOrder.cpp:
1137         (JSC::B3::Air::blocksInOptimizedOrder):
1138         * b3/air/AirSpecial.cpp:
1139         (JSC::B3::Air::Special::isTerminal):
1140         (JSC::B3::Air::Special::hasNonArgEffects):
1141         (JSC::B3::Air::Special::hasNonArgNonControlEffects):
1142         * b3/air/AirSpecial.h:
1143         * b3/air/AirValidate.cpp:
1144         * b3/air/opcode_generator.rb:
1145         * b3/testb3.cpp:
1146
1147 2016-07-24  Filip Pizlo  <fpizlo@apple.com>
1148
1149         Unreviewed, fix broken test. I don't know why I goofed this up without seeing it before landing.
1150
1151         * b3/air/AirOpcode.opcodes:
1152         * b3/testb3.cpp:
1153         (JSC::B3::run):
1154
1155 2016-07-22  Filip Pizlo  <fpizlo@apple.com>
1156
1157         [B3] Fusing immediates into test instructions should work again
1158         https://bugs.webkit.org/show_bug.cgi?id=160073
1159
1160         Reviewed by Sam Weinig.
1161
1162         When we introduced BitImm, we forgot to change the Branch(BitAnd(value, constant))
1163         fusion.  This emits test instructions, so it should use BitImm for the constant.  But it
1164         was still using Imm!  This meant that isValidForm() always returned false.
1165         
1166         This fixes the code path to use BitImm, and turns off our use of BitImm64 on x86 since
1167         it provides no benefit on x86 and has some risk (the code appears to play fast and loose
1168         with the scratch register).
1169         
1170         This is not an obvious progression on anything, so I added comprehensive tests to
1171         testb3, which check that we selected the optimal instruction in a variety of situations.
1172         We should add more tests like this!
1173
1174         * b3/B3BasicBlock.h:
1175         (JSC::B3::BasicBlock::successorBlock):
1176         * b3/B3LowerToAir.cpp:
1177         (JSC::B3::Air::LowerToAir::createGenericCompare):
1178         * b3/B3LowerToAir.h:
1179         * b3/air/AirArg.cpp:
1180         (JSC::B3::Air::Arg::isRepresentableAs):
1181         (JSC::B3::Air::Arg::usesTmp):
1182         * b3/air/AirArg.h:
1183         (JSC::B3::Air::Arg::isRepresentableAs):
1184         (JSC::B3::Air::Arg::castToType):
1185         (JSC::B3::Air::Arg::asNumber):
1186         * b3/air/AirCode.h:
1187         (JSC::B3::Air::Code::size):
1188         (JSC::B3::Air::Code::at):
1189         * b3/air/AirOpcode.opcodes:
1190         * b3/air/AirValidate.h:
1191         * b3/air/opcode_generator.rb:
1192         * b3/testb3.cpp:
1193         (JSC::B3::compile):
1194         (JSC::B3::compileAndRun):
1195         (JSC::B3::lowerToAirForTesting):
1196         (JSC::B3::testSomeEarlyRegister):
1197         (JSC::B3::testBranchBitAndImmFusion):
1198         (JSC::B3::zero):
1199         (JSC::B3::run):
1200
1201 2016-07-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1202
1203         Unreviewed, update the exponentiation expression error message
1204         https://bugs.webkit.org/show_bug.cgi?id=159969
1205
1206         Follow up patch for r203499.
1207
1208         * parser/Parser.cpp:
1209         (JSC::Parser<LexerType>::parseBinaryExpression):
1210         * tests/stress/pow-expects-update-expression-on-lhs.js:
1211         (throw.new.Error):
1212
1213 2016-07-24  Darin Adler  <darin@apple.com>
1214
1215         Adding a new WebCore JavaScript built-in source file does not trigger rebuild of WebCoreJSBuiltins*
1216         https://bugs.webkit.org/show_bug.cgi?id=160115
1217
1218         Reviewed by Youenn Fablet.
1219
1220         * make-generated-sources.sh: Removed. Was unused.
1221
1222 2016-07-23  Commit Queue  <commit-queue@webkit.org>
1223
1224         Unreviewed, rolling out r203641.
1225         https://bugs.webkit.org/show_bug.cgi?id=160116
1226
1227         It broke make-based builds (Requested by youenn on #webkit).
1228
1229         Reverted changeset:
1230
1231         "[Fetch API] Request should be created with any HeadersInit
1232         data"
1233         https://bugs.webkit.org/show_bug.cgi?id=159672
1234         http://trac.webkit.org/changeset/203641
1235
1236 2016-07-23  Youenn Fablet  <youenn@apple.com>
1237
1238         [Fetch API] Request should be created with any HeadersInit data
1239         https://bugs.webkit.org/show_bug.cgi?id=159672
1240
1241         Reviewed by Sam Weinig.
1242
1243         * Scripts/builtins/builtins_generator.py:
1244         (WK_lcfirst): Synchronized with CodeGenerator.pm version.
1245
1246 2016-07-21  Filip Pizlo  <fpizlo@apple.com>
1247
1248         Teach MarkedSpace how to allocate auxiliary storage
1249         https://bugs.webkit.org/show_bug.cgi?id=160053
1250
1251         Reviewed by Sam Weinig.
1252         
1253         Previously, we had two kinds of subspaces in MarkedSpace: destructor and non-destructor. This
1254         was described using "bool needsDestruction" that would get passed around. We'd iterate over
1255         these spaces using duplicated code - one loop for destructors and one for non-destructors, or
1256         a single loop that does one thing for destructors and one for non-destructors.
1257         
1258         But now we want a third subspace: non-destructor non-JSCell, aka Auxiliary.
1259         
1260         So, this changes all of the reflection and iteration over subspaces to use functors, so that
1261         the looping is written once and reused. Most places don't even have to know that there is a
1262         third subspace; they just know that they must do things for each subspace, for each
1263         allocator, or for each block - and the functor magic handles it for you.
1264         
1265         To make this somewhat nice, this change also fixes how we describe subspaces. Instead of a
1266         bool, we now have AllocatorAttributes, which is a struct. If we ever add more subspaces, we
1267         can add fields to AllocatorAttributes to describe how those subspaces differ. For now it just
1268         contains two properties: a DestructionMode and a HeapCell::Kind. The DesctructionMode
1269         replaces bool needsDestruction. I deliberately used a non-class enum to avoid tautologies.
1270         DestructionMode has two members: NeedsDestruction and DoesNotNeedDestruction. I almost went
1271         with DestructionMode::Needed and DestructionMode::NotNeeded, but I felt like that involves
1272         more typing and doesn't actually avoid any kind of namespace issues.
1273         
1274         This is intended to have no behavior change other than the addition of a totally unused
1275         space, which should always be empty. So hopefully it doesn't cost anything.
1276
1277         * CMakeLists.txt:
1278         * JavaScriptCore.xcodeproj/project.pbxproj:
1279         * heap/AllocatorAttributes.cpp: Added.
1280         (JSC::AllocatorAttributes::dump):
1281         * heap/AllocatorAttributes.h: Added.
1282         (JSC::AllocatorAttributes::AllocatorAttributes):
1283         * heap/DestructionMode.cpp: Added.
1284         (WTF::printInternal):
1285         * heap/DestructionMode.h: Added.
1286         * heap/Heap.h:
1287         * heap/MarkedAllocator.cpp:
1288         (JSC::MarkedAllocator::allocateBlock):
1289         (JSC::MarkedAllocator::addBlock):
1290         * heap/MarkedAllocator.h:
1291         (JSC::MarkedAllocator::cellSize):
1292         (JSC::MarkedAllocator::attributes):
1293         (JSC::MarkedAllocator::needsDestruction):
1294         (JSC::MarkedAllocator::destruction):
1295         (JSC::MarkedAllocator::cellKind):
1296         (JSC::MarkedAllocator::heap):
1297         (JSC::MarkedAllocator::takeLastActiveBlock):
1298         (JSC::MarkedAllocator::MarkedAllocator):
1299         (JSC::MarkedAllocator::init):
1300         (JSC::MarkedAllocator::allocate):
1301         * heap/MarkedBlock.cpp:
1302         (JSC::MarkedBlock::create):
1303         (JSC::MarkedBlock::destroy):
1304         (JSC::MarkedBlock::MarkedBlock):
1305         (JSC::MarkedBlock::callDestructor):
1306         (JSC::MarkedBlock::sweep):
1307         (JSC::MarkedBlock::stopAllocating):
1308         (JSC::MarkedBlock::didRetireBlock):
1309         * heap/MarkedBlock.h:
1310         (JSC::MarkedBlock::cellSize):
1311         (JSC::MarkedBlock::attributes):
1312         (JSC::MarkedBlock::needsDestruction):
1313         (JSC::MarkedBlock::destruction):
1314         (JSC::MarkedBlock::cellKind):
1315         (JSC::MarkedBlock::size):
1316         (JSC::MarkedBlock::forEachCell):
1317         (JSC::MarkedBlock::forEachLiveCell):
1318         (JSC::MarkedBlock::forEachDeadCell):
1319         * heap/MarkedSpace.cpp:
1320         (JSC::MarkedSpace::MarkedSpace):
1321         (JSC::MarkedSpace::~MarkedSpace):
1322         (JSC::MarkedSpace::lastChanceToFinalize):
1323         (JSC::MarkedSpace::resetAllocators):
1324         (JSC::MarkedSpace::forEachAllocator):
1325         (JSC::MarkedSpace::stopAllocating):
1326         (JSC::MarkedSpace::resumeAllocating):
1327         (JSC::MarkedSpace::isPagedOut):
1328         (JSC::MarkedSpace::freeBlock):
1329         (JSC::MarkedSpace::shrink):
1330         (JSC::MarkedSpace::clearNewlyAllocated):
1331         (JSC::clearNewlyAllocatedInBlock): Deleted.
1332         * heap/MarkedSpace.h:
1333         (JSC::MarkedSpace::subspaceForObjectsWithDestructor):
1334         (JSC::MarkedSpace::subspaceForObjectsWithoutDestructor):
1335         (JSC::MarkedSpace::subspaceForAuxiliaryData):
1336         (JSC::MarkedSpace::allocatorFor):
1337         (JSC::MarkedSpace::destructorAllocatorFor):
1338         (JSC::MarkedSpace::auxiliaryAllocatorFor):
1339         (JSC::MarkedSpace::allocateWithoutDestructor):
1340         (JSC::MarkedSpace::allocateWithDestructor):
1341         (JSC::MarkedSpace::allocateAuxiliary):
1342         (JSC::MarkedSpace::forEachBlock):
1343         (JSC::MarkedSpace::didAddBlock):
1344         (JSC::MarkedSpace::capacity):
1345         (JSC::MarkedSpace::forEachSubspace):
1346
1347 2016-07-22  Saam Barati  <sbarati@apple.com>
1348
1349         REGRESSION(r203537): It made many tests crash on ARMv7 Linux platforms
1350         https://bugs.webkit.org/show_bug.cgi?id=160082
1351
1352         Reviewed by Keith Miller.
1353
1354         We were improperly linking the Jump in the link buffer.
1355         It caused us to be linking against the executable address
1356         which always has bit 0 set. We shouldn't be doing that.
1357         This patch fixes this, by using the same idiom that
1358         PolymorphicAccess uses to link a jump to out of line code.
1359
1360         * jit/JITMathIC.h:
1361         (JSC::JITMathIC::generateOutOfLine):
1362
1363 2016-07-22  Commit Queue  <commit-queue@webkit.org>
1364
1365         Unreviewed, rolling out r203603.
1366         https://bugs.webkit.org/show_bug.cgi?id=160096
1367
1368         Caused CLoop tests to fail with assertions (Requested by
1369         perarne on #webkit).
1370
1371         Reverted changeset:
1372
1373         "[Win] jsc.exe sometimes never exits."
1374         https://bugs.webkit.org/show_bug.cgi?id=158073
1375         http://trac.webkit.org/changeset/203603
1376
1377 2016-07-22  Per Arne Vollan  <pvollan@apple.com>
1378
1379         [Win] jsc.exe sometimes never exits.
1380         https://bugs.webkit.org/show_bug.cgi?id=158073
1381
1382         Reviewed by Mark Lam.
1383
1384         Make sure the VM is deleted after the test has finished. This will gracefully stop the sampling profiler thread,
1385         and give the thread the opportunity to release the machine thread lock aquired in SamplingProfiler::takeSample.  
1386         If the sampling profiler thread was terminated while holding the machine thread lock, the machine thread will
1387         not be able to grab the lock afterwards. 
1388  
1389         * jsc.cpp:
1390         (jscmain):
1391
1392 2016-07-22  Per Arne Vollan  <pvollan@apple.com>
1393
1394         Fix the Windows 64-bit build after r203537
1395         https://bugs.webkit.org/show_bug.cgi?id=160080
1396
1397         Reviewed by Csaba Osztrogonác.
1398
1399         Added new version of setupArgumentsWithExecState method.
1400
1401         * jit/CCallHelpers.h:
1402         (JSC::CCallHelpers::setupArgumentsWithExecState):
1403
1404 2016-07-22  Csaba Osztrogonác  <ossy@webkit.org>
1405
1406         [ARM] Unreviewed EABI buildfix after r203537.
1407
1408         * jit/CCallHelpers.h:
1409         (JSC::CCallHelpers::setupArgumentsWithExecState): Added.
1410
1411 2016-07-22  Youenn Fablet  <youenn@apple.com>
1412
1413         run-builtins-generator-tests should be able to test WebCore builtins wrapper with more than one file
1414         https://bugs.webkit.org/show_bug.cgi?id=159921
1415
1416         Reviewed by Brian Burg.
1417
1418         Updated built-in generator to generate only wrapper files when passed the --wrappers-only option.
1419         When this option is used, wrapper files are generated but no individual file is generated.
1420         When this option is not used, individual files are generated but not wrapper file is generated.
1421         This allows the builtin generator test runner to generate a single WebCore-Wrappers.h-result generated for all
1422         WebCore test files, like used for real in WebCore.
1423         Previously wrapper code was generated individually for each WebCore test file.
1424
1425         Added new built-in test file to cover the case of concatenating several guards in generated WebCore wrapper files.
1426
1427         * Scripts/generate-js-builtins.py:
1428         (concatenated_output_filename): Compute a decent name for wrapper files in case of test mode.
1429         (generate_bindings_for_builtins_files): When --wrappers-only is activated, this generates only the wrapper files, not the individual files.
1430         * Scripts/tests/builtins/WebCore-AnotherGuardedInternalBuiltin-Separate.js: Added.
1431         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result: Added.
1432         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Removed wrapper code.
1433         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
1434         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
1435         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
1436         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Removed wrapper code.
1437         * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result: Added, contains wrapper code for all WebCore valid test cases.
1438
1439 2016-07-21  Saam Barati  <sbarati@apple.com>
1440
1441         callOperation(.) variants in the DFG that explicitly take a tag/payload register should take a JSValueRegs instead
1442         https://bugs.webkit.org/show_bug.cgi?id=160007
1443
1444         Reviewed by Filip Pizlo.
1445
1446         This patch is the first step in my plan to remove all callOperation(.) variants
1447         in the various JITs and to unify them using a couple template variations.
1448         The steps are as follows:
1449         1. Replace all explicit tag/payload pairs with JSValueRegs in the DFG
1450         2. Replace all explicit tag/payload pairs with JSValueRegs in the baseline
1451         3. remove callOperation(.) variants and teach setupArgumentsWithExecState
1452            about JSValueRegs.
1453
1454         * dfg/DFGSpeculativeJIT.cpp:
1455         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
1456         (JSC::DFG::SpeculativeJIT::compileValueAdd):
1457         (JSC::DFG::SpeculativeJIT::compileGetDynamicVar):
1458         (JSC::DFG::SpeculativeJIT::compilePutDynamicVar):
1459         (JSC::DFG::SpeculativeJIT::compilePutAccessorByVal):
1460         * dfg/DFGSpeculativeJIT.h:
1461         (JSC::DFG::SpeculativeJIT::callOperation):
1462         * dfg/DFGSpeculativeJIT32_64.cpp:
1463         (JSC::DFG::SpeculativeJIT::cachedGetById):
1464         (JSC::DFG::SpeculativeJIT::cachedPutById):
1465         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1466         (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::generateInternal):
1467         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
1468         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1469         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1470         (JSC::DFG::SpeculativeJIT::emitCall):
1471         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
1472         (JSC::DFG::SpeculativeJIT::emitBranch):
1473         (JSC::DFG::SpeculativeJIT::compile):
1474
1475 2016-07-21  Saam Barati  <sbarati@apple.com>
1476
1477         op_add/ValueAdd should be an IC in all JIT tiers
1478         https://bugs.webkit.org/show_bug.cgi?id=159649
1479
1480         Reviewed by Benjamin Poulain.
1481
1482         This patch makes Add an IC inside all JIT tiers. It does so in a
1483         simple, but effective, way. We will try to generate an int+int add
1484         that will repatch itself if its type checks fail. Sometimes though,
1485         we have runtime type data saying that the add won't be int+int.
1486         In those cases, we will just generate a full snippet that doesn't patch itself.
1487         Other times, we may generate no inline code and defer to making a C call. A lot
1488         of this patch is just refactoring ResultProfile into what we're now calling ArithProfile.
1489         ArithProfile does everything ResultProfile used to do, and more. It records simple type
1490         data about the LHS/RHS operands it sees. This allows us to determine if an op_add
1491         has only seen int+int operands, etc. ArithProfile will also contain the ResultType
1492         for the LHS/RHS that the parser feeds into op_add. ArithProfile now fits into 32-bits.
1493         This means instead of having a side table like we did for ResultProfile, we just
1494         inject the ArithProfile into the bytecode instruction stream. This makes asking
1495         for ArithProfile faster; we no longer need to lock around this operation.
1496
1497         The size of an Add has gone down on average, but we can still do better.
1498         We still generate a lot of code because we generate calls to the slow path.
1499         I think we can make this better by moving the slow path to a shared thunk
1500         system. This patch mostly lays the foundation for future improvements to Add,
1501         and a framework to move all other arithmetic operations to be typed-based ICs.
1502
1503         Here is some data I took on the average op_add/ValueAdd size on various benchmarks:
1504                    |   JetStream  |  Speedometer |  Unity 3D  |
1505              ------| -------------|-----------------------------
1506               Old  |  189 bytes   |  169 bytes   |  192 bytes |
1507              ------| -------------|-----------------------------
1508               New  |  148 bytes   |  124 bytes   |  143 bytes |
1509              ---------------------------------------------------
1510
1511         Making an arithmetic IC is now easy. The JITMathIC class will hold a snippet
1512         generator as a member variable. To make a snippet an IC, you need to implement
1513         a generateInline(.) method, which generates the inline IC. Then, you need to
1514         generate the IC where you used to generate the snippet. When generating the
1515         IC, we need to inform JITMathIC of various data like we do with StructureStubInfo.
1516         We need to tell it about where the slow path starts, where the slow path call is, etc.
1517         When generating a JITMathIC, it may tell you that it didn't generate any code inline.
1518         This is a request to the user of JITMathIC to just generate a C call along the
1519         fast path. JITMathIC may also have the snippet tell it to just generate the full
1520         snippet instead of the int+int path along the fast path.
1521
1522         In subsequent patches, we can improve upon how we decide to generate int+int or
1523         the full snippet. I tried to get clever by having double+double, double+int, int+double,
1524         fast paths, but they didn't work out nearly as well as the int+int fast path. I ended up
1525         generating a lot of code when I did this and ended up using more memory than just generating
1526         the full snippet. There is probably some way we can be clever and generate specialized fast
1527         paths that are more successful than what I tried implementing, but I think that's worth deferring
1528         this to follow up patches once the JITMathIC foundation has landed.
1529
1530         This patch also fixes a bug inside the slow path lambdas in the DFG.
1531         Before, it was not legal to emit an exception check inside them. Now,
1532         it is. So it's now easy to define arbitrary late paths using the DFG
1533         slow path lambda API.
1534
1535         * CMakeLists.txt:
1536         * JavaScriptCore.xcodeproj/project.pbxproj:
1537         * bytecode/ArithProfile.cpp: Added.
1538         (JSC::ArithProfile::emitObserveResult):
1539         (JSC::ArithProfile::shouldEmitSetDouble):
1540         (JSC::ArithProfile::emitSetDouble):
1541         (JSC::ArithProfile::shouldEmitSetNonNumber):
1542         (JSC::ArithProfile::emitSetNonNumber):
1543         (WTF::printInternal):
1544         * bytecode/ArithProfile.h: Added.
1545         (JSC::ObservedType::ObservedType):
1546         (JSC::ObservedType::sawInt32):
1547         (JSC::ObservedType::isOnlyInt32):
1548         (JSC::ObservedType::sawNumber):
1549         (JSC::ObservedType::isOnlyNumber):
1550         (JSC::ObservedType::sawNonNumber):
1551         (JSC::ObservedType::isOnlyNonNumber):
1552         (JSC::ObservedType::isEmpty):
1553         (JSC::ObservedType::bits):
1554         (JSC::ObservedType::withInt32):
1555         (JSC::ObservedType::withNumber):
1556         (JSC::ObservedType::withNonNumber):
1557         (JSC::ObservedType::withoutNonNumber):
1558         (JSC::ObservedType::operator==):
1559         (JSC::ArithProfile::ArithProfile):
1560         (JSC::ArithProfile::fromInt):
1561         (JSC::ArithProfile::lhsResultType):
1562         (JSC::ArithProfile::rhsResultType):
1563         (JSC::ArithProfile::lhsObservedType):
1564         (JSC::ArithProfile::rhsObservedType):
1565         (JSC::ArithProfile::setLhsObservedType):
1566         (JSC::ArithProfile::setRhsObservedType):
1567         (JSC::ArithProfile::tookSpecialFastPath):
1568         (JSC::ArithProfile::didObserveNonInt32):
1569         (JSC::ArithProfile::didObserveDouble):
1570         (JSC::ArithProfile::didObserveNonNegZeroDouble):
1571         (JSC::ArithProfile::didObserveNegZeroDouble):
1572         (JSC::ArithProfile::didObserveNonNumber):
1573         (JSC::ArithProfile::didObserveInt32Overflow):
1574         (JSC::ArithProfile::didObserveInt52Overflow):
1575         (JSC::ArithProfile::setObservedNonNegZeroDouble):
1576         (JSC::ArithProfile::setObservedNegZeroDouble):
1577         (JSC::ArithProfile::setObservedNonNumber):
1578         (JSC::ArithProfile::setObservedInt32Overflow):
1579         (JSC::ArithProfile::setObservedInt52Overflow):
1580         (JSC::ArithProfile::addressOfBits):
1581         (JSC::ArithProfile::observeResult):
1582         (JSC::ArithProfile::lhsSawInt32):
1583         (JSC::ArithProfile::lhsSawNumber):
1584         (JSC::ArithProfile::lhsSawNonNumber):
1585         (JSC::ArithProfile::rhsSawInt32):
1586         (JSC::ArithProfile::rhsSawNumber):
1587         (JSC::ArithProfile::rhsSawNonNumber):
1588         (JSC::ArithProfile::observeLHSAndRHS):
1589         (JSC::ArithProfile::bits):
1590         (JSC::ArithProfile::hasBits):
1591         (JSC::ArithProfile::setBit):
1592         * bytecode/CodeBlock.cpp:
1593         (JSC::CodeBlock::dumpRareCaseProfile):
1594         (JSC::CodeBlock::dumpArithProfile):
1595         (JSC::CodeBlock::dumpBytecode):
1596         (JSC::CodeBlock::addStubInfo):
1597         (JSC::CodeBlock::addJITAddIC):
1598         (JSC::CodeBlock::findStubInfo):
1599         (JSC::CodeBlock::resetJITData):
1600         (JSC::CodeBlock::shrinkToFit):
1601         (JSC::CodeBlock::dumpValueProfiles):
1602         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
1603         (JSC::CodeBlock::arithProfileForBytecodeOffset):
1604         (JSC::CodeBlock::arithProfileForPC):
1605         (JSC::CodeBlock::couldTakeSpecialFastCase):
1606         (JSC::CodeBlock::dumpResultProfile): Deleted.
1607         (JSC::CodeBlock::resultProfileForBytecodeOffset): Deleted.
1608         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
1609         (JSC::CodeBlock::ensureResultProfile): Deleted.
1610         * bytecode/CodeBlock.h:
1611         (JSC::CodeBlock::stubInfoBegin):
1612         (JSC::CodeBlock::stubInfoEnd):
1613         (JSC::CodeBlock::couldTakeSlowCase):
1614         (JSC::CodeBlock::numberOfResultProfiles): Deleted.
1615         * bytecode/MethodOfGettingAValueProfile.cpp:
1616         (JSC::MethodOfGettingAValueProfile::emitReportValue):
1617         * bytecode/MethodOfGettingAValueProfile.h:
1618         (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile):
1619         * bytecode/ValueProfile.cpp:
1620         (JSC::ResultProfile::emitDetectNumericness): Deleted.
1621         (JSC::ResultProfile::emitSetDouble): Deleted.
1622         (JSC::ResultProfile::emitSetNonNumber): Deleted.
1623         (WTF::printInternal): Deleted.
1624         * bytecode/ValueProfile.h:
1625         (JSC::getRareCaseProfileBytecodeOffset):
1626         (JSC::ResultProfile::ResultProfile): Deleted.
1627         (JSC::ResultProfile::bytecodeOffset): Deleted.
1628         (JSC::ResultProfile::specialFastPathCount): Deleted.
1629         (JSC::ResultProfile::didObserveNonInt32): Deleted.
1630         (JSC::ResultProfile::didObserveDouble): Deleted.
1631         (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted.
1632         (JSC::ResultProfile::didObserveNegZeroDouble): Deleted.
1633         (JSC::ResultProfile::didObserveNonNumber): Deleted.
1634         (JSC::ResultProfile::didObserveInt32Overflow): Deleted.
1635         (JSC::ResultProfile::didObserveInt52Overflow): Deleted.
1636         (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted.
1637         (JSC::ResultProfile::setObservedNegZeroDouble): Deleted.
1638         (JSC::ResultProfile::setObservedNonNumber): Deleted.
1639         (JSC::ResultProfile::setObservedInt32Overflow): Deleted.
1640         (JSC::ResultProfile::setObservedInt52Overflow): Deleted.
1641         (JSC::ResultProfile::addressOfFlags): Deleted.
1642         (JSC::ResultProfile::addressOfSpecialFastPathCount): Deleted.
1643         (JSC::ResultProfile::detectNumericness): Deleted.
1644         (JSC::ResultProfile::hasBits): Deleted.
1645         (JSC::ResultProfile::setBit): Deleted.
1646         (JSC::getResultProfileBytecodeOffset): Deleted.
1647         * bytecompiler/BytecodeGenerator.cpp:
1648         (JSC::BytecodeGenerator::emitBinaryOp):
1649         * dfg/DFGByteCodeParser.cpp:
1650         (JSC::DFG::ByteCodeParser::makeSafe):
1651         * dfg/DFGGraph.cpp:
1652         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1653         * dfg/DFGJITCompiler.cpp:
1654         (JSC::DFG::JITCompiler::exceptionCheck):
1655         * dfg/DFGSlowPathGenerator.h:
1656         (JSC::DFG::SlowPathGenerator::generate):
1657         * dfg/DFGSpeculativeJIT.cpp:
1658         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
1659         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
1660         (JSC::DFG::SpeculativeJIT::compileValueAdd):
1661         * dfg/DFGSpeculativeJIT.h:
1662         (JSC::DFG::SpeculativeJIT::silentSpillAllRegistersImpl):
1663         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
1664         (JSC::DFG::SpeculativeJIT::callOperation):
1665         * ftl/FTLLowerDFGToB3.cpp:
1666         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
1667         (JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
1668         * jit/CCallHelpers.h:
1669         (JSC::CCallHelpers::setupArgumentsWithExecState):
1670         (JSC::CCallHelpers::setupArguments):
1671         * jit/JIT.h:
1672         * jit/JITAddGenerator.cpp:
1673         (JSC::JITAddGenerator::generateInline):
1674         (JSC::JITAddGenerator::generateFastPath):
1675         * jit/JITAddGenerator.h:
1676         (JSC::JITAddGenerator::JITAddGenerator):
1677         (JSC::JITAddGenerator::didEmitFastPath): Deleted.
1678         (JSC::JITAddGenerator::endJumpList): Deleted.
1679         (JSC::JITAddGenerator::slowPathJumpList): Deleted.
1680         * jit/JITArithmetic.cpp:
1681         (JSC::JIT::emit_op_jless):
1682         (JSC::JIT::emitSlow_op_urshift):
1683         (JSC::getOperandTypes):
1684         (JSC::JIT::emit_op_add):
1685         (JSC::JIT::emitSlow_op_add):
1686         (JSC::JIT::emit_op_div):
1687         (JSC::JIT::emit_op_mul):
1688         (JSC::JIT::emitSlow_op_mul):
1689         (JSC::JIT::emit_op_sub):
1690         (JSC::JIT::emitSlow_op_sub):
1691         * jit/JITDivGenerator.cpp:
1692         (JSC::JITDivGenerator::generateFastPath):
1693         * jit/JITDivGenerator.h:
1694         (JSC::JITDivGenerator::JITDivGenerator):
1695         * jit/JITInlines.h:
1696         (JSC::JIT::callOperation):
1697         * jit/JITMathIC.h: Added.
1698         (JSC::JITMathIC::doneLocation):
1699         (JSC::JITMathIC::slowPathStartLocation):
1700         (JSC::JITMathIC::slowPathCallLocation):
1701         (JSC::JITMathIC::generateInline):
1702         (JSC::JITMathIC::generateOutOfLine):
1703         (JSC::JITMathIC::finalizeInlineCode):
1704         * jit/JITMathICForwards.h: Added.
1705         * jit/JITMathICInlineResult.h: Added.
1706         * jit/JITMulGenerator.cpp:
1707         (JSC::JITMulGenerator::generateFastPath):
1708         * jit/JITMulGenerator.h:
1709         (JSC::JITMulGenerator::JITMulGenerator):
1710         * jit/JITOperations.cpp:
1711         * jit/JITOperations.h:
1712         * jit/JITSubGenerator.cpp:
1713         (JSC::JITSubGenerator::generateFastPath):
1714         * jit/JITSubGenerator.h:
1715         (JSC::JITSubGenerator::JITSubGenerator):
1716         * jit/Repatch.cpp:
1717         (JSC::readCallTarget):
1718         (JSC::ftlThunkAwareRepatchCall):
1719         (JSC::tryCacheGetByID):
1720         (JSC::repatchGetByID):
1721         (JSC::appropriateGenericPutByIdFunction):
1722         (JSC::tryCachePutByID):
1723         (JSC::repatchPutByID):
1724         (JSC::tryRepatchIn):
1725         (JSC::repatchIn):
1726         (JSC::linkSlowFor):
1727         (JSC::resetGetByID):
1728         (JSC::resetPutByID):
1729         (JSC::repatchCall): Deleted.
1730         * jit/Repatch.h:
1731         * llint/LLIntData.cpp:
1732         (JSC::LLInt::Data::performAssertions):
1733         * llint/LowLevelInterpreter.asm:
1734         * llint/LowLevelInterpreter32_64.asm:
1735         * llint/LowLevelInterpreter64.asm:
1736         * parser/ResultType.h:
1737         (JSC::ResultType::ResultType):
1738         (JSC::ResultType::isInt32):
1739         (JSC::ResultType::definitelyIsNumber):
1740         (JSC::ResultType::definitelyIsString):
1741         (JSC::ResultType::definitelyIsBoolean):
1742         (JSC::ResultType::mightBeNumber):
1743         (JSC::ResultType::isNotNumber):
1744         (JSC::ResultType::forBitOp):
1745         (JSC::ResultType::bits):
1746         (JSC::OperandTypes::OperandTypes):
1747         * runtime/CommonSlowPaths.cpp:
1748         (JSC::SLOW_PATH_DECL):
1749         (JSC::updateArithProfileForBinaryArithOp):
1750         (JSC::updateResultProfileForBinaryArithOp): Deleted.
1751         * tests/stress/op-add-exceptions.js: Added.
1752         (assert):
1753         (f1):
1754         (f2):
1755         (f3):
1756         (let.oException.valueOf):
1757         (foo):
1758         (ident):
1759         (bar):
1760
1761 2016-07-21  Csaba Osztrogonác  <ossy@webkit.org>
1762
1763         Clarify testing mode names in run-jsc-stress-tests
1764         https://bugs.webkit.org/show_bug.cgi?id=160021
1765
1766         Reviewed by Mark Lam.
1767
1768         Default should mean really default, not default with disabled FTL, renamed
1769         - runMozillaTestDefault to runMozillaTestNoFTL
1770         - runMozillaTestDefaultFTL to runMozillaTestDefault
1771         - runDefault to runNoFTL
1772         - runDefaultFTL to runDefault
1773         - runLayoutTestDefault to runLayoutTestNoFTL
1774         - runLayoutTestDefaultFTL to runLayoutTestDefault
1775         - runNoisyTestDefault to runNoisyTestNoFTL
1776         - runNoisyTestDefaultFTL to runNoisyTestDefault
1777
1778         * tests/mozilla/mozilla-tests.yaml:
1779         * tests/stress/lift-tdz-bypass-catch.js:
1780         * tests/stress/obscure-error-message-dont-crash.js:
1781         * tests/stress/shadow-chicken-disabled.js:
1782
1783 2016-07-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1784
1785         [ES7] Introduce exponentiation expression
1786         https://bugs.webkit.org/show_bug.cgi?id=159969
1787
1788         Reviewed by Saam Barati.
1789
1790         This patch implements the exponentiation expression, e.g. `x ** y`.
1791         The exponentiation expression is introduced in ECMA262 2016 and ECMA262 2016
1792         is already released. So this is not the draft spec.
1793
1794         The exponentiation expression has 2 interesting points.
1795
1796         1. Right associative
1797
1798             To follow the Math expression, ** operator is right associative.
1799             When we execute `x ** y ** z`, this is handled as `x ** (y ** z)`, not `(x ** y) ** z`.
1800             This patch introduces the right associativity to the binary operator and handles it
1801             in the operator precedence parser in Parser.cpp.
1802
1803         2. LHS of the exponentiation expression is UpdateExpression
1804
1805             ExponentiationExpression[Yield]:
1806                 UnaryExpression[?Yield]
1807                 UpdateExpression[?Yield] ** ExponentiationExpression[?Yield]
1808
1809             As we can see, the left hand side of the ExponentiationExpression is UpdateExpression, not UnaryExpression.
1810             It means that `+x ** y` becomes a syntax error. This is intentional. Without superscript in JS,
1811             `-x**y` is confusing between `-(x ** y)` and `(-x) ** y`. So ECMA262 intentionally avoids UnaryExpression here.
1812             If we need to use a negated value, we need to write parentheses explicitly e.g. `(-x) ** y`.
1813             In this patch, we ensure that the left hand side is not an unary expression by checking an operator in
1814             parseBinaryExpression. This works since `**` has the highest operator precedence in the binary operators.
1815
1816         We introduce a new bytecode, op_pow. That simply works as similar as the other binary operators.
1817         And it is converted to ArithPow in DFG and handled in DFG and FTL.
1818         In this patch, we take the approach just introducing a new bytecode instead of calling Math.pow.
1819         This is because we would like to execute ToNumber in the caller side, not in the callee (Math.pow) side.
1820         And we don't want to compile ** into the following.
1821
1822             lhsNumber = to_number (lhs)
1823             rhsNumber = to_number (rhs)
1824             call Math.pow(lhsNumber, rhsNumber)
1825
1826         We ensure that this patch passes all the test262 tests related to the exponentiation expression.
1827
1828         The only sensitive part to the performance is the parser changes.
1829         So we measured the code-load performance and it is neutral in my x64 Linux box (hanayamata).
1830
1831             Collected 30 samples per benchmark/VM, with 30 VM invocations per benchmark. Emitted a call to
1832             gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used
1833             the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark
1834             execution times with 95% confidence intervals in milliseconds.
1835
1836                                      baseline                  patched
1837
1838             closure              0.60499+-0.00250          0.60180+-0.00244
1839             jquery               7.89175+-0.02433    ?     7.91287+-0.04759       ?
1840
1841             <geometric>          2.18499+-0.00523          2.18207+-0.00689         might be 1.0013x faster
1842
1843         * bytecode/BytecodeList.json:
1844         * bytecode/BytecodeUseDef.h:
1845         (JSC::computeUsesForBytecodeOffset):
1846         (JSC::computeDefsForBytecodeOffset):
1847         * bytecode/CodeBlock.cpp:
1848         (JSC::CodeBlock::dumpBytecode):
1849         * bytecompiler/NodesCodegen.cpp:
1850         (JSC::emitReadModifyAssignment):
1851         * dfg/DFGByteCodeParser.cpp:
1852         (JSC::DFG::ByteCodeParser::parseBlock):
1853         * dfg/DFGCapabilities.cpp:
1854         (JSC::DFG::capabilityLevel):
1855         * jit/JIT.cpp:
1856         (JSC::JIT::privateCompileMainPass):
1857         * jit/JIT.h:
1858         * jit/JITArithmetic.cpp:
1859         (JSC::JIT::emit_op_pow):
1860         * llint/LowLevelInterpreter.asm:
1861         * parser/ASTBuilder.h:
1862         (JSC::ASTBuilder::operatorStackShouldReduce):
1863         (JSC::ASTBuilder::makePowNode):
1864         (JSC::ASTBuilder::makeMultNode):
1865         (JSC::ASTBuilder::makeDivNode):
1866         (JSC::ASTBuilder::makeModNode):
1867         (JSC::ASTBuilder::makeSubNode):
1868         (JSC::ASTBuilder::makeBinaryNode):
1869         (JSC::ASTBuilder::operatorStackHasHigherPrecedence): Deleted.
1870         * parser/Lexer.cpp:
1871         (JSC::Lexer<T>::lex):
1872         * parser/NodeConstructors.h:
1873         (JSC::PowNode::PowNode):
1874         * parser/Nodes.h:
1875         * parser/Parser.cpp:
1876         (JSC::Parser<LexerType>::parseAssignmentExpression):
1877         (JSC::isUnaryOpExcludingUpdateOp):
1878         (JSC::Parser<LexerType>::parseBinaryExpression):
1879         (JSC::isUnaryOp): Deleted.
1880         * parser/ParserTokens.h:
1881         (JSC::isUpdateOp):
1882         (JSC::isUnaryOp):
1883         * parser/SyntaxChecker.h:
1884         (JSC::SyntaxChecker::operatorStackPop):
1885         * runtime/CommonSlowPaths.cpp:
1886         (JSC::SLOW_PATH_DECL):
1887         * runtime/CommonSlowPaths.h:
1888         * tests/stress/pow-basics.js: Added.
1889         (valuesAreClose):
1890         (mathPowDoubleDouble1):
1891         (mathPowDoubleInt1):
1892         (test1):
1893         (mathPowDoubleDouble2):
1894         (mathPowDoubleInt2):
1895         (test2):
1896         (mathPowDoubleDouble3):
1897         (mathPowDoubleInt3):
1898         (test3):
1899         (mathPowDoubleDouble4):
1900         (mathPowDoubleInt4):
1901         (test4):
1902         (mathPowDoubleDouble5):
1903         (mathPowDoubleInt5):
1904         (test5):
1905         (mathPowDoubleDouble6):
1906         (mathPowDoubleInt6):
1907         (test6):
1908         (mathPowDoubleDouble7):
1909         (mathPowDoubleInt7):
1910         (test7):
1911         (mathPowDoubleDouble8):
1912         (mathPowDoubleInt8):
1913         (test8):
1914         (mathPowDoubleDouble9):
1915         (mathPowDoubleInt9):
1916         (test9):
1917         (mathPowDoubleDouble10):
1918         (mathPowDoubleInt10):
1919         (test10):
1920         (mathPowDoubleDouble11):
1921         (mathPowDoubleInt11):
1922         (test11):
1923         * tests/stress/pow-coherency.js: Added.
1924         (pow42):
1925         (build42AsDouble.opaqueAdd):
1926         (build42AsDouble):
1927         (powDouble42):
1928         (clobber):
1929         (pow42NoConstantFolding):
1930         (powDouble42NoConstantFolding):
1931         * tests/stress/pow-evaluation-order.js: Added.
1932         (shouldBe):
1933         (throw.new.Error):
1934         * tests/stress/pow-expects-update-expression-on-lhs.js: Added.
1935         (testSyntax):
1936         (testSyntaxError):
1937         (throw.new.Error):
1938         (let.token.of.tokens.testSyntax.pow):
1939         (testSyntax.pow):
1940         * tests/stress/pow-integer-exponent-fastpath.js: Added.
1941         (valuesAreClose):
1942         (mathPowDoubleDoubleTestExponentFifty):
1943         (mathPowDoubleIntTestExponentFifty):
1944         (testExponentFifty):
1945         (mathPowDoubleDoubleTestExponentTenThousands):
1946         (mathPowDoubleIntTestExponentTenThousands):
1947         (testExponentTenThousands):
1948         * tests/stress/pow-nan-behaviors.js: Added.
1949         (testIntegerBaseWithNaNExponentStatic):
1950         (mathPowIntegerBaseWithNaNExponentDynamic):
1951         (testIntegerBaseWithNaNExponentDynamic):
1952         (testFloatingPointBaseWithNaNExponentStatic):
1953         (mathPowFloatingPointBaseWithNaNExponentDynamic):
1954         (testFloatingPointBaseWithNaNExponentDynamic):
1955         (testNaNBaseStatic):
1956         (mathPowNaNBaseDynamic1):
1957         (mathPowNaNBaseDynamic2):
1958         (mathPowNaNBaseDynamic3):
1959         (mathPowNaNBaseDynamic4):
1960         (testNaNBaseDynamic):
1961         (infiniteExponentsStatic):
1962         (mathPowInfiniteExponentsDynamic1):
1963         (mathPowInfiniteExponentsDynamic2):
1964         (mathPowInfiniteExponentsDynamic3):
1965         (mathPowInfiniteExponentsDynamic4):
1966         (infiniteExponentsDynamic):
1967         * tests/stress/pow-simple.js: Added.
1968         (shouldBe):
1969         (throw.new.Error):
1970         * tests/stress/pow-stable-results.js: Added.
1971         (opaquePow):
1972         (isIdentical):
1973         * tests/stress/pow-to-number-should-be-executed-in-code-side.js: Added.
1974         (shouldBe):
1975         (throw.new.Error):
1976         * tests/stress/pow-with-constants.js: Added.
1977         (exponentIsZero):
1978         (testExponentIsZero):
1979         (exponentIsOne):
1980         (testExponentIsOne):
1981         (powUsedAsSqrt):
1982         (testPowUsedAsSqrt):
1983         (powUsedAsOneOverSqrt):
1984         (testPowUsedAsOneOverSqrt):
1985         (powUsedAsSquare):
1986         (testPowUsedAsSquare):
1987         (intIntConstantsSmallNumbers):
1988         (intIntConstantsLargeNumbers):
1989         (intIntSmallConstants):
1990         (intDoubleConstants):
1991         (doubleDoubleConstants):
1992         (doubleIntConstants):
1993         (testBaseAndExponentConstantLiterals):
1994         (exponentIsIntegerConstant):
1995         (testExponentIsIntegerConstant):
1996         (exponentIsDoubleConstant):
1997         (testExponentIsDoubleConstant):
1998         (exponentIsInfinityConstant):
1999         (testExponentIsInfinityConstant):
2000         (exponentIsNegativeInfinityConstant):
2001         (testExponentIsNegativeInfinityConstant):
2002         * tests/stress/pow-with-never-NaN-exponent.js: Added.
2003         (exponentIsNonNanDouble1):
2004         (exponentIsNonNanDouble2):
2005         (testExponentIsDoubleConstant):
2006         * tests/test262.yaml:
2007
2008 2016-07-18  Filip Pizlo  <fpizlo@apple.com>
2009
2010         Switching on symbols should be fast
2011         https://bugs.webkit.org/show_bug.cgi?id=158892
2012
2013         Reviewed by Keith Miller.
2014         
2015         This does two things: fixes some goofs in our lowering of symbol equality and adds a new phase
2016         to B3 to infer switch statements from linear chains of branches.
2017         
2018         This changes how we compile equality to Symbols to constant-fold the load of the Symbol's UID.
2019         This is necessary for making switches on Symbols inferrable. This also gives us the ability to
2020         efficiently compile strict equality comparisons of SymbolUse and UntypedUse.
2021
2022         This adds a new phase to B3, which finds chains of branches that test for (in)equality on the
2023         same value and constants, and turns them into a Switch. This can turn O(n) code into
2024         O(log n) code, or even O(1) code if the switch cases are dense.
2025         
2026         This can make a big difference in JS. Say you write a switch in which the case statements are
2027         variable resolutions. The bytecode generator cannot use a bytecode switch in this case, since
2028         we're required to evaluate the resolutions in order. But in DFG IR, we will often turn those
2029         variable resolutions into constants, since we do that for any immutable singleton. This means
2030         that B3 will see a chain of Branches: the else case of one Branch will point to a basic block
2031         that does nothing but Branch on equality on the same value as the first Branch.
2032
2033         The inference algorithm is quite simple. The basic building block is the ability to summarize
2034         a block's switch behavior. For a block that ends in a switch, this is just the collection of
2035         switch cases. For a block that ends in a branch, we recognize Branch(Equal(value, const)),
2036         Branch(NotEqual(value, const)), and Branch(value). Each of these are summarized as if they
2037         were one-case switches. We infer a new switch if both some block and its sole predecessor
2038         can be described as switches on the same value, nothing shady is going on (like loops), and
2039         the block in question does no work other than this switch. In that case, the block is killed
2040         and its cases (which we get from the summary) are added to the predecessor's switch. This
2041         algorithm runs to fixpoint.
2042         
2043         * CMakeLists.txt:
2044         * JavaScriptCore.xcodeproj/project.pbxproj:
2045         * b3/B3Generate.cpp:
2046         (JSC::B3::generateToAir):
2047         * b3/B3InferSwitches.cpp: Added.
2048         (JSC::B3::inferSwitches):
2049         * b3/B3InferSwitches.h: Added.
2050         * b3/B3Procedure.h:
2051         (JSC::B3::Procedure::cfg):
2052         * b3/B3ReduceStrength.cpp:
2053         * b3/B3Value.cpp:
2054         (JSC::B3::Value::performSubstitution):
2055         (JSC::B3::Value::isFree):
2056         (JSC::B3::Value::dumpMeta):
2057         * b3/B3Value.h:
2058         * ftl/FTLLowerDFGToB3.cpp:
2059         (JSC::FTL::DFG::LowerDFGToB3::compileCheckIdent):
2060         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
2061         (JSC::FTL::DFG::LowerDFGToB3::lowSymbol):
2062         (JSC::FTL::DFG::LowerDFGToB3::lowSymbolUID):
2063         (JSC::FTL::DFG::LowerDFGToB3::lowNonNullObject):
2064
2065 2016-07-20  Filip Pizlo  <fpizlo@apple.com>
2066
2067         FTL snippet generators should be able to request a different register for output and input
2068         https://bugs.webkit.org/show_bug.cgi?id=160010
2069         rdar://problem/27439330
2070
2071         Reviewed by Saam Barati.
2072         
2073         The BitOr and BitXor snippet generators have problems if the register for the right input is
2074         the same as the register for the result. We could fix those generators, but I'm not convinced
2075         that the other snippet generators don't have this bug. So, the approach that this patch takes
2076         is to teach the FTL to request that B3 to use a different register for the result than for
2077         any input to the snippet patchpoint.
2078         
2079         Air already has the ability to let any instruction do an EarlyDef, which means exactly this.
2080         But B3 did not expose this via ValueRep. This patch exposes this in ValueRep as
2081         SomeEarlyRegister. That's most of the change.
2082         
2083         This adds a testb3 test for SomeEarlyRegister and a regression test for this particular
2084         problem. The regression test failed on trunk JSC before this.
2085
2086         * b3/B3LowerToAir.cpp:
2087         (JSC::B3::Air::LowerToAir::lower):
2088         * b3/B3PatchpointSpecial.cpp:
2089         (JSC::B3::PatchpointSpecial::forEachArg):
2090         (JSC::B3::PatchpointSpecial::admitsStack):
2091         * b3/B3StackmapSpecial.cpp:
2092         (JSC::B3::StackmapSpecial::forEachArgImpl):
2093         (JSC::B3::StackmapSpecial::isArgValidForRep):
2094         * b3/B3Validate.cpp:
2095         * b3/B3ValueRep.cpp:
2096         (JSC::B3::ValueRep::addUsedRegistersTo):
2097         (JSC::B3::ValueRep::dump):
2098         (WTF::printInternal):
2099         * b3/B3ValueRep.h:
2100         (JSC::B3::ValueRep::ValueRep):
2101         (JSC::B3::ValueRep::reg):
2102         (JSC::B3::ValueRep::isAny):
2103         (JSC::B3::ValueRep::isReg):
2104         (JSC::B3::ValueRep::isSomeRegister): Deleted.
2105         * b3/testb3.cpp:
2106         * ftl/FTLLowerDFGToB3.cpp:
2107         (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
2108         (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
2109         (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
2110         * tests/stress/ftl-bit-xor-right-result-interference.js: Added.
2111
2112 2016-07-20  Michael Saboff  <msaboff@apple.com>
2113
2114         CrashOnOverflow in JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets
2115         https://bugs.webkit.org/show_bug.cgi?id=159954
2116
2117         Reviewed by Benjamin Poulain.
2118
2119         YarrPatternConstructor::setupAlternativeOffsets() is using the checked arithmetic class
2120         Checked<>, for offset calculations.  However the default use will just crash on
2121         overflow.  Instead we should stop processing and propagate the error up the call stack.
2122
2123         Consolidated explicit error string with the common RegExp parsing error logic.
2124         Moved that logic to YarrPattern as that seems like a better common place to put it.
2125
2126         * jit/JITOperations.cpp:
2127         * llint/LLIntSlowPaths.cpp:
2128         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2129         * tests/stress/regress-159954.js: New test.
2130         * yarr/YarrParser.h:
2131         (JSC::Yarr::Parser::CharacterClassParserDelegate::CharacterClassParserDelegate):
2132         (JSC::Yarr::Parser::CharacterClassParserDelegate::atomPatternCharacter):
2133         (JSC::Yarr::Parser::Parser):
2134         (JSC::Yarr::Parser::isIdentityEscapeAnError):
2135         (JSC::Yarr::Parser::parseEscape):
2136         (JSC::Yarr::Parser::parseCharacterClass):
2137         (JSC::Yarr::Parser::parseParenthesesBegin):
2138         (JSC::Yarr::Parser::parseParenthesesEnd):
2139         (JSC::Yarr::Parser::parseQuantifier):
2140         (JSC::Yarr::Parser::parseTokens):
2141         (JSC::Yarr::Parser::parse):
2142         * yarr/YarrPattern.cpp:
2143         (JSC::Yarr::YarrPatternConstructor::disjunction):
2144         (JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):
2145         (JSC::Yarr::YarrPatternConstructor::setupOffsets):
2146         (JSC::Yarr::YarrPattern::errorMessage):
2147         (JSC::Yarr::YarrPattern::compile):
2148         * yarr/YarrPattern.h:
2149         (JSC::Yarr::YarrPattern::reset):
2150
2151 2016-07-19  Filip Pizlo  <fpizlo@apple.com>
2152
2153         The default testing mode should not involve disabling the FTL JIT
2154         https://bugs.webkit.org/show_bug.cgi?id=159929
2155
2156         Rubber stamped by Mark Lam and Saam Barati.
2157         
2158         Use the new powers to make some tests run only in the default configuration (i.e. FTL,
2159         concurrent JIT).
2160
2161         * tests/mozilla/mozilla-tests.yaml:
2162
2163 2016-07-19  Keith Miller  <keith_miller@apple.com>
2164
2165         Test262 should have a file with the revision and url
2166         https://bugs.webkit.org/show_bug.cgi?id=159937
2167
2168         Reviewed by Mark Lam.
2169
2170         The file.
2171
2172         * tests/test262/test262-Revision.txt: Added.
2173
2174 2016-07-19  Anders Carlsson  <andersca@apple.com>
2175
2176         WebCore-7602.1.42 fails to build: error: private field 'm_vm' is not used
2177         https://bugs.webkit.org/show_bug.cgi?id=159944
2178         rdar://problem/27420308
2179
2180         Reviewed by Dan Bernstein.
2181
2182         Wrap the m_vm declaration and initialization in conditional guards.
2183
2184         * Scripts/builtins/builtins_generate_internals_wrapper_header.py:
2185         (generate_members):
2186         * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
2187         (BuiltinsInternalsWrapperImplementationGenerator.generate_constructor):
2188         Add guards.
2189
2190         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
2191         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
2192         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
2193         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
2194         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2195         Update expected results.
2196
2197 2016-07-19  Filip Pizlo  <fpizlo@apple.com>
2198
2199         REGRESSION (r203348-r203368): ASSERTION FAILED: from.isCell() && from.asCell()->JSCell::inherits(std::remove_pointer<To>::type::info())
2200         https://bugs.webkit.org/show_bug.cgi?id=159930
2201
2202         Reviewed by Geoffrey Garen.
2203         
2204         The problem is that the 32-bit DFG can flush the scope register as an unboxed cell, but the
2205         Register::scope() method was causing us to assert that it's a JSValue with proper cell
2206         boxing. We could have forced the DFG to flush it as a boxed JSValue, but I don't think that
2207         would have made anything better. This fixes the issue by teaching Register::scope() that it
2208         might see unboxed cells.
2209
2210         * runtime/JSScope.h:
2211         (JSC::Register::scope):
2212         (JSC::ExecState::lexicalGlobalObject):
2213
2214 2016-07-19  Filip Pizlo  <fpizlo@apple.com>
2215
2216         B3 methods that mutate the successors array should take FrequentedBlock by value
2217         https://bugs.webkit.org/show_bug.cgi?id=159935
2218
2219         Reviewed by Michael Saboff.
2220         
2221         This bug was found by ASan testing. setSuccessors() takes a const FrequentedBlock&, and the
2222         caller that caused the ASan crash was doing:
2223
2224         block->setSuccessors(block->notTaken())
2225
2226         So, inside setSuccessors(), after we resize() the successors array, the const
2227         FrequentedBlock& points to nonsense.
2228
2229         The fix is to pass FrequentedBlock by value in all of these kinds of methods.
2230         
2231         No new tests, but ASan testing catches this instantly for anything that triggers CFG
2232         simplification in B3. So like half of our tests.
2233
2234         * b3/B3BasicBlock.cpp:
2235         (JSC::B3::BasicBlock::clearSuccessors):
2236         (JSC::B3::BasicBlock::appendSuccessor):
2237         (JSC::B3::BasicBlock::setSuccessors):
2238         * b3/B3BasicBlock.h:
2239         (JSC::B3::BasicBlock::successors):
2240         (JSC::B3::BasicBlock::successorBlock):
2241         * b3/B3Value.cpp:
2242         (JSC::B3::Value::replaceWithPhi):
2243         (JSC::B3::Value::replaceWithJump):
2244         (JSC::B3::Value::replaceWithOops):
2245         * b3/B3Value.h:
2246
2247 2016-07-18  Joseph Pecoraro  <pecoraro@apple.com>
2248
2249         Make builtin TypeErrors consistent
2250         https://bugs.webkit.org/show_bug.cgi?id=159899
2251
2252         Reviewed by Keith Miller.
2253
2254         Converge on the single TypeError for non-coercible this objects in builtins.
2255         Also update some other style to be more consistent with-in builtins.
2256
2257         * builtins/ArrayIteratorPrototype.js:
2258         (next):
2259         * builtins/ArrayPrototype.js:
2260         (values):
2261         (keys):
2262         (entries):
2263         (reduce):
2264         (reduceRight):
2265         (every):
2266         (forEach):
2267         (filter):
2268         (map):
2269         (some):
2270         (fill):
2271         (find):
2272         (findIndex):
2273         (includes):
2274         (sort):
2275         (concatSlowPath):
2276         (copyWithin):
2277         * builtins/StringPrototype.js:
2278         (match):
2279         (repeat):
2280         (padStart):
2281         (padEnd):
2282         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2283         (localeCompare):
2284         (search):
2285         (split):
2286         * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
2287         * tests/es6/String.prototype_methods_String.prototype.padStart.js:
2288         * tests/stress/array-iterators-next-error-messages.js:
2289         (catch):
2290         * tests/stress/array-iterators-next-with-call.js:
2291         * tests/stress/regexp-match.js:
2292         (shouldThrow):
2293         * tests/stress/regexp-search.js:
2294         (shouldThrow):
2295
2296 2016-07-17  Filip Pizlo  <fpizlo@apple.com>
2297
2298         Implement table-based switches in B3/Air
2299         https://bugs.webkit.org/show_bug.cgi?id=151141
2300
2301         Reviewed by Benjamin Poulain.
2302
2303         If a switch statement gets large, it's better to express it as an indirect jump rather than
2304         using a binary switch (divide-and-conquer tree of comparisons leading to O(log n) branches to
2305         get to the switch case). When dealing with integer switches, FTL will already use the B3
2306         Switch and expect this to get lowered as efficiently as possible; it's a bug that B3 will
2307         always use a binary switch rather than indirect jumps. When dealing with switches over some
2308         more sophisticated types, we'd want FTL to build an indirect jump table itself and use
2309         something like a hashtable to feed it. In that case, there will be no B3 Switch; we'll want
2310         some way for the FTL to directly express an indirection jump when emitting B3.
2311         
2312         This implies that we want B3 to have the ability to lower Switch to indirect jumps and to
2313         expose those indirect jumps in IR so that the FTL could do its own indirect jumps for
2314         switches over more complicated things like strings. But indirect jumps are tough to express
2315         in IR. For example, the LLVM approach ("indirectbr" and "blockaddress", see
2316         http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html) means that some
2317         control flow edges cannot be split. Indirectbr takes an address as input and jumps to it, and
2318         blockaddress lets you build jump tables out of basic block addresses. This means that the
2319         compiler can never change any successor of an indirectbr, since the client will have already
2320         arranged for that indirectbr to jump to exactly those successors. We don't want such
2321         restrictions in B3, since B3 relies on being able to break critical edges for SSA conversion.
2322         Also, indirectbr is not cloneable, which would break any hope of doing specialization-based
2323         transformations like we want to do for multiple entrypoints (bug 159391). The goal of this
2324         change is to let clients do indirect jumps without placing any restrictions on IR.
2325         
2326         The trick is to allow Patchpoints to be used as block terminals. Patchpoints already allow
2327         clients of B3 to emit whatever code they like. Patchpoints are friendly to B3's other
2328         transformations because the client of the patchpoint has to play along with whatever
2329         decisions B3 had made around the patchpoint: what registers got used, what the control flow
2330         looks like, etc. Patchpoints can even be cloned by B3, and the client has to accommodate this
2331         in their patchpoint generator. It turns out that using Patchpoints as terminals is quite
2332         natural. We accomplish this by moving the successor edges out of ControlValue and into
2333         BasicBlock, and removing ControlValue entirely. This way, any Value subclass can be a
2334         terminal. It was already true that a Value is a terminal if value->effects().terminal, which
2335         works great with Patchpoints since they control their effects via PatchpointValue::effects.
2336         You can make your Patchpoint into a terminal by placing it at the end of a block and doing:
2337         
2338         patchpoint->effects.terminal = true;
2339         
2340         A Patchpoints in terminal position gets access to additional API in StackmapGenerationParams.
2341         The generator can get a Box<Label> for each successor to its owning block. For example, to
2342         implement a jump-table-based switch, you would make your patchpoint take the table index as
2343         its sole input. Inside the generator, you allocate the jump table and emit a BaseIndex jump
2344         that uses the jump table pointer (which will be a constant known to the generator since it
2345         just allocated it) as the base and the patchpoint input as an index. The jump table can be
2346         populated by MacroAssemblerCodePtr's computed by installing a link task to resolve the labels
2347         to concrete locations. This change makes LowerMacros do such a lowering for Switches that can
2348         benefit from jump tables. This happens recursively: if the original Switch is too sparse, we
2349         will divide-and-conquer as before. If at any recursion step we find that the remaining cases
2350         are dense and large enough to profit from a jump table, then those cases will be lowered to a
2351         Patchpoint that does the table jump. This is a fun way to do stepwise lowering: LowerMacros
2352         is essentially pre-lowering the Switch directly to machine code, and wrapping that machine
2353         code in a Patchpoint so that the rest of the compiler doesn't have to know anything about
2354         what happened. I suspect that in the future we will want to do other pre-lowerings this way,
2355         whenever the B3 IR phases have some special knowledge about what machine code should be
2356         emitted and it would be annoying to drag that knowledge through the rest of the compiler.
2357         
2358         One downside of this change is that we used ControlValue in so many places. Most of this
2359         patch involves removing references to ControlValue. It would be less than 100kb if it wasn't
2360         for that. To make this a bit easier, I added "appendNewControlValue" methods to BasicBlock,
2361         which allocate a Value and set the successors as if you had done "appendNew<ControlValue>".
2362         This made for an easy search-and-replace in testb3 and FTLOutput. I filed bug 159440 to
2363         remove this ugly stopgap method.
2364         
2365         I think that we will also end up using this facility to extend our use of snippets. We
2366         already use shared snippet generators for the generic forms of arithmetic. We will probably
2367         also want to do this for generic forms of branches. This wouldn't have been possible prior to
2368         this change, since there would have been no way to emit a control snippet in FTL. Now we can
2369         emit control snippets using terminal patchpoints.
2370
2371         This is a ~30% speed-up on microbenchmarks that have big switch statements (~60 cases). It's
2372         not a speed-up on mainstream benchmarks.
2373         
2374         This also adds a new test to testb3 for terminal Patchpoints, Get, and Set. The FTL does not
2375         currently use terminal Patchpoints directly, but we want this to be possible. It also doesn't
2376         use Get/Set directly even though we want this to be possible. It's important to test these
2377         since opcodes that result from lowering don't affect early phases, so we could have
2378         regressions in early phases related to these opcodes that wouldn't be caught by any JS test.
2379         So, this adds a very basic threaded interpreter to testb3 for a Brainfuck-style language, and
2380         tests it by having it run a program that prints the numbers 1..100 in a loop. Unlike a real
2381         threaded interpreter, it uses a common dispatch block rather than having dispatch at the
2382         terminus of each opcode. That's necessary because PolyJump is not cloneable. The state of the
2383         interpreter is represented using Variables that we Get and Set, so it tests Get/Set as well.
2384
2385         * CMakeLists.txt:
2386         * JavaScriptCore.xcodeproj/project.pbxproj:
2387         * assembler/MacroAssemblerARM64.h:
2388         (JSC::MacroAssemblerARM64::jump):
2389         * assembler/MacroAssemblerX86Common.h:
2390         (JSC::MacroAssemblerX86Common::jump):
2391         * assembler/X86Assembler.h:
2392         (JSC::X86Assembler::jmp_m):
2393         * b3/B3BasicBlock.cpp:
2394         (JSC::B3::BasicBlock::append):
2395         (JSC::B3::BasicBlock::appendNonTerminal):
2396         (JSC::B3::BasicBlock::removeLast):
2397         (JSC::B3::BasicBlock::appendIntConstant):
2398         (JSC::B3::BasicBlock::clearSuccessors):
2399         (JSC::B3::BasicBlock::appendSuccessor):
2400         (JSC::B3::BasicBlock::setSuccessors):
2401         (JSC::B3::BasicBlock::replaceSuccessor):
2402         (JSC::B3::BasicBlock::addPredecessor):
2403         (JSC::B3::BasicBlock::deepDump):
2404         (JSC::B3::BasicBlock::appendNewControlValue):
2405         * b3/B3BasicBlock.h:
2406         (JSC::B3::BasicBlock::numSuccessors):
2407         (JSC::B3::BasicBlock::successor):
2408         (JSC::B3::BasicBlock::successors):
2409         (JSC::B3::BasicBlock::successorBlock):
2410         (JSC::B3::BasicBlock::successorBlocks):
2411         (JSC::B3::BasicBlock::numPredecessors):
2412         (JSC::B3::BasicBlock::predecessor):
2413         (JSC::B3::BasicBlock::frequency):
2414         * b3/B3BasicBlockInlines.h:
2415         (JSC::B3::BasicBlock::replaceLastWithNew):
2416         (JSC::B3::BasicBlock::taken):
2417         (JSC::B3::BasicBlock::notTaken):
2418         (JSC::B3::BasicBlock::fallThrough):
2419         (JSC::B3::BasicBlock::numSuccessors): Deleted.
2420         (JSC::B3::BasicBlock::successor): Deleted.
2421         (JSC::B3::BasicBlock::successors): Deleted.
2422         (JSC::B3::BasicBlock::successorBlock): Deleted.
2423         (JSC::B3::BasicBlock::successorBlocks): Deleted.
2424         * b3/B3BlockInsertionSet.cpp:
2425         (JSC::B3::BlockInsertionSet::splitForward):
2426         * b3/B3BreakCriticalEdges.cpp:
2427         (JSC::B3::breakCriticalEdges):
2428         * b3/B3CaseCollection.cpp: Added.
2429         (JSC::B3::CaseCollection::dump):
2430         * b3/B3CaseCollection.h: Added.
2431         (JSC::B3::CaseCollection::CaseCollection):
2432         (JSC::B3::CaseCollection::operator[]):
2433         (JSC::B3::CaseCollection::iterator::iterator):
2434         (JSC::B3::CaseCollection::iterator::operator*):
2435         (JSC::B3::CaseCollection::iterator::operator++):
2436         (JSC::B3::CaseCollection::iterator::operator==):
2437         (JSC::B3::CaseCollection::iterator::operator!=):
2438         (JSC::B3::CaseCollection::begin):
2439         (JSC::B3::CaseCollection::end):
2440         * b3/B3CaseCollectionInlines.h: Added.
2441         (JSC::B3::CaseCollection::fallThrough):
2442         (JSC::B3::CaseCollection::size):
2443         (JSC::B3::CaseCollection::at):
2444         * b3/B3CheckSpecial.cpp:
2445         (JSC::B3::CheckSpecial::CheckSpecial):
2446         (JSC::B3::CheckSpecial::hiddenBranch):
2447         * b3/B3Common.h:
2448         (JSC::B3::is64Bit):
2449         * b3/B3ControlValue.cpp: Removed.
2450         * b3/B3ControlValue.h: Removed.
2451         * b3/B3DataSection.cpp:
2452         (JSC::B3::DataSection::DataSection):
2453         * b3/B3DuplicateTails.cpp:
2454         * b3/B3FixSSA.cpp:
2455         * b3/B3FoldPathConstants.cpp:
2456         * b3/B3LowerMacros.cpp:
2457         * b3/B3LowerToAir.cpp:
2458         (JSC::B3::Air::LowerToAir::run):
2459         (JSC::B3::Air::LowerToAir::lower):
2460         * b3/B3MathExtras.cpp:
2461         (JSC::B3::powDoubleInt32):
2462         * b3/B3Opcode.h:
2463         (JSC::B3::isConstant):
2464         (JSC::B3::isDefinitelyTerminal):
2465         * b3/B3PatchpointSpecial.cpp:
2466         (JSC::B3::PatchpointSpecial::generate):
2467         (JSC::B3::PatchpointSpecial::isTerminal):
2468         (JSC::B3::PatchpointSpecial::dumpImpl):
2469         * b3/B3PatchpointSpecial.h:
2470         * b3/B3Procedure.cpp:
2471         (JSC::B3::Procedure::resetReachability):
2472         * b3/B3Procedure.h:
2473         (JSC::B3::Procedure::lastPhaseName):
2474         (JSC::B3::Procedure::byproducts):
2475         * b3/B3ReduceStrength.cpp:
2476         * b3/B3StackmapGenerationParams.cpp:
2477         (JSC::B3::StackmapGenerationParams::unavailableRegisters):
2478         (JSC::B3::StackmapGenerationParams::successorLabels):
2479         (JSC::B3::StackmapGenerationParams::fallsThroughToSuccessor):
2480         (JSC::B3::StackmapGenerationParams::proc):
2481         * b3/B3StackmapGenerationParams.h:
2482         (JSC::B3::StackmapGenerationParams::gpScratch):
2483         (JSC::B3::StackmapGenerationParams::fpScratch):
2484         * b3/B3SwitchValue.cpp:
2485         (JSC::B3::SwitchValue::~SwitchValue):
2486         (JSC::B3::SwitchValue::removeCase):
2487         (JSC::B3::SwitchValue::hasFallThrough):
2488         (JSC::B3::SwitchValue::setFallThrough):
2489         (JSC::B3::SwitchValue::appendCase):
2490         (JSC::B3::SwitchValue::dumpSuccessors):
2491         (JSC::B3::SwitchValue::dumpMeta):
2492         (JSC::B3::SwitchValue::cloneImpl):
2493         (JSC::B3::SwitchValue::SwitchValue):
2494         * b3/B3SwitchValue.h:
2495         (JSC::B3::SwitchValue::accepts):
2496         (JSC::B3::SwitchValue::caseValues):
2497         (JSC::B3::SwitchValue::cases):
2498         (JSC::B3::SwitchValue::fallThrough): Deleted.
2499         (JSC::B3::SwitchValue::size): Deleted.
2500         (JSC::B3::SwitchValue::at): Deleted.
2501         (JSC::B3::SwitchValue::operator[]): Deleted.
2502         (JSC::B3::SwitchValue::iterator::iterator): Deleted.
2503         (JSC::B3::SwitchValue::iterator::operator*): Deleted.
2504         (JSC::B3::SwitchValue::iterator::operator++): Deleted.
2505         (JSC::B3::SwitchValue::iterator::operator==): Deleted.
2506         (JSC::B3::SwitchValue::iterator::operator!=): Deleted.
2507         (JSC::B3::SwitchValue::begin): Deleted.
2508         (JSC::B3::SwitchValue::end): Deleted.
2509         * b3/B3Validate.cpp:
2510         * b3/B3Value.cpp:
2511         (JSC::B3::Value::replaceWithPhi):
2512         (JSC::B3::Value::replaceWithJump):
2513         (JSC::B3::Value::replaceWithOops):
2514         (JSC::B3::Value::dump):
2515         (JSC::B3::Value::deepDump):
2516         (JSC::B3::Value::dumpSuccessors):
2517         (JSC::B3::Value::negConstant):
2518         (JSC::B3::Value::typeFor):
2519         * b3/B3Value.h:
2520         * b3/air/AirCode.cpp:
2521         (JSC::B3::Air::Code::addFastTmp):
2522         (JSC::B3::Air::Code::addDataSection):
2523         (JSC::B3::Air::Code::jsHash):
2524         * b3/air/AirCode.h:
2525         (JSC::B3::Air::Code::isFastTmp):
2526         (JSC::B3::Air::Code::setLastPhaseName):
2527         * b3/air/AirCustom.h:
2528         (JSC::B3::Air::PatchCustom::shouldTryAliasingDef):
2529         (JSC::B3::Air::PatchCustom::isTerminal):
2530         (JSC::B3::Air::PatchCustom::hasNonArgNonControlEffects):
2531         (JSC::B3::Air::PatchCustom::generate):
2532         (JSC::B3::Air::CCallCustom::admitsStack):
2533         (JSC::B3::Air::CCallCustom::isTerminal):
2534         (JSC::B3::Air::CCallCustom::hasNonArgNonControlEffects):
2535         (JSC::B3::Air::ShuffleCustom::admitsStack):
2536         (JSC::B3::Air::ShuffleCustom::isTerminal):
2537         (JSC::B3::Air::ShuffleCustom::hasNonArgNonControlEffects):
2538         * b3/air/AirGenerate.cpp:
2539         (JSC::B3::Air::generate):
2540         * b3/air/AirGenerationContext.h:
2541         * b3/air/AirInst.h:
2542         (JSC::B3::Air::Inst::hasNonControlEffects):
2543         * b3/air/AirSimplifyCFG.cpp:
2544         (JSC::B3::Air::simplifyCFG):
2545         * b3/air/AirSpecial.cpp:
2546         (JSC::B3::Air::Special::shouldTryAliasingDef):
2547         (JSC::B3::Air::Special::isTerminal):
2548         (JSC::B3::Air::Special::hasNonArgNonControlEffects):
2549         * b3/air/AirSpecial.h:
2550         * b3/air/AirValidate.cpp:
2551         * b3/air/opcode_generator.rb:
2552         * b3/testb3.cpp:
2553         * ftl/FTLLowerDFGToB3.cpp:
2554         * ftl/FTLOutput.cpp:
2555         (JSC::FTL::Output::jump):
2556         (JSC::FTL::Output::branch):
2557         (JSC::FTL::Output::ret):
2558         (JSC::FTL::Output::unreachable):
2559         (JSC::FTL::Output::speculate):
2560         (JSC::FTL::Output::trap):
2561         (JSC::FTL::Output::anchor):
2562         (JSC::FTL::Output::decrementSuperSamplerCount):
2563         (JSC::FTL::Output::addIncomingToPhi):
2564         * ftl/FTLOutput.h:
2565         (JSC::FTL::Output::constIntPtr):
2566         (JSC::FTL::Output::callWithoutSideEffects):
2567         (JSC::FTL::Output::switchInstruction):
2568         (JSC::FTL::Output::phi):
2569         (JSC::FTL::Output::addIncomingToPhi):
2570
2571 2016-07-18  Anders Carlsson  <andersca@apple.com>
2572
2573         WebKit nightly fails to build on macOS Sierra
2574         https://bugs.webkit.org/show_bug.cgi?id=159902
2575         rdar://problem/27365672
2576
2577         Reviewed by Tim Horton.
2578
2579         * icu/unicode/ucurr.h: Added.
2580         Add ucurr.h from ICU.
2581
2582 2016-07-18  Michael Saboff  <msaboff@apple.com>
2583
2584         ASSERTION FAILED: : (year >= 1970 && yearday >= 0) || (year < 1970 && yearday < 0) -- WTF/wtf/DateMath.cpp
2585         https://bugs.webkit.org/show_bug.cgi?id=159883
2586
2587         Reviewed by Filip Pizlo.
2588
2589         New test.
2590
2591         * tests/stress/regress-159883.js: Added.
2592
2593 2016-07-12  Filip Pizlo  <fpizlo@apple.com>
2594
2595         MarkedBlocks should know that they can be used for more than JSCells
2596         https://bugs.webkit.org/show_bug.cgi?id=159643
2597
2598         Reviewed by Geoffrey Garen.
2599         
2600         This teaches the Heap that a MarkedBlock may hold either JSCells, or Auxiliary, which is
2601         not a JSCell. It teaches the heap and all of the things that walk the heap to ignore
2602         non-JSCells whenever they are looking for global objects, JSObjects, and things to trace
2603         for debugging or profiling. The idea is that we will be able to allocate butterflies and
2604         typed array backing stores as Auxiliary in MarkedSpace rather than allocating those things
2605         in CopiedSpace. That's what bug 159658 is all about.
2606         
2607         This gives us a new type, called HeapCell, which is just meant to be a class distinct from
2608         JSCell or any type we would use for Auxiliary. For convenience, JSCell is a subclass of
2609         HeapCell. HeapCell has an enum called HeapCell::Kind, which is either HeapCell::JSCell or
2610         HeapCell::Auxiliary. MarkedSpace no longer speaks of JSCells directly except when dealing
2611         with destruction.
2612         
2613         This change required doing a lot of stuff to all of those functor callbacks, since they
2614         now take HeapCell* instead of JSCell* and they take an extra HeapCell::Kind argument to
2615         tell them if they are dealing with JSCells or Auxiliary. I figured that this would be as
2616         good a time as any to convert those functors to being lambda-compatible. This means that
2617         operator() must be const. In some cases, converting the operator() to be const would have
2618         taken more work than just turning the whole thing into a lambda. Whenever this was the
2619         case, I converted the code to use lambdas. I left a lot of functors alone. In cases where
2620         the functor would benefit from being a lambda, for example because it would get rid of
2621         const_casts or mutables, I put in a FIXME referencing bug 159644.
2622
2623         * CMakeLists.txt:
2624         * JavaScriptCore.xcodeproj/project.pbxproj:
2625         * debugger/Debugger.cpp:
2626         (JSC::Debugger::SetSteppingModeFunctor::SetSteppingModeFunctor):
2627         (JSC::Debugger::SetSteppingModeFunctor::operator()):
2628         (JSC::Debugger::ToggleBreakpointFunctor::ToggleBreakpointFunctor):
2629         (JSC::Debugger::ToggleBreakpointFunctor::operator()):
2630         (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::ClearCodeBlockDebuggerRequestsFunctor):
2631         (JSC::Debugger::ClearCodeBlockDebuggerRequestsFunctor::operator()):
2632         (JSC::Debugger::ClearDebuggerRequestsFunctor::ClearDebuggerRequestsFunctor):
2633         (JSC::Debugger::ClearDebuggerRequestsFunctor::operator()):
2634         * heap/CodeBlockSet.h:
2635         (JSC::CodeBlockSet::iterate):
2636         * heap/HandleSet.h:
2637         (JSC::HandleNode::next):
2638         (JSC::HandleSet::forEachStrongHandle):
2639         * heap/Heap.cpp:
2640         (JSC::GatherHeapSnapshotData::GatherHeapSnapshotData):
2641         (JSC::GatherHeapSnapshotData::operator()):
2642         (JSC::RemoveDeadHeapSnapshotNodes::RemoveDeadHeapSnapshotNodes):
2643         (JSC::RemoveDeadHeapSnapshotNodes::operator()):
2644         (JSC::Heap::protectedGlobalObjectCount):
2645         (JSC::Heap::globalObjectCount):
2646         (JSC::Heap::protectedObjectCount):
2647         (JSC::Heap::protectedObjectTypeCounts):
2648         (JSC::Heap::objectTypeCounts):
2649         (JSC::Heap::deleteAllCodeBlocks):
2650         (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor):
2651         (JSC::MarkedBlockSnapshotFunctor::operator()):
2652         (JSC::Zombify::visit):
2653         (JSC::Zombify::operator()):
2654         (JSC::Heap::zombifyDeadObjects):
2655         (JSC::Heap::flushWriteBarrierBuffer):
2656         * heap/Heap.h:
2657         (JSC::Heap::handleSet):
2658         (JSC::Heap::handleStack):
2659         * heap/HeapCell.cpp: Added.
2660         (WTF::printInternal):
2661         * heap/HeapCell.h: Added.
2662         (JSC::HeapCell::HeapCell):
2663         (JSC::HeapCell::zap):
2664         (JSC::HeapCell::isZapped):
2665         * heap/HeapInlines.h:
2666         (JSC::Heap::deprecatedReportExtraMemory):
2667         (JSC::Heap::forEachCodeBlock):
2668         (JSC::Heap::forEachProtectedCell):
2669         (JSC::Heap::allocateWithDestructor):
2670         * heap/HeapStatistics.cpp:
2671         (JSC::StorageStatistics::visit):
2672         (JSC::StorageStatistics::operator()):
2673         * heap/HeapVerifier.cpp:
2674         (JSC::GatherLiveObjFunctor::visit):
2675         (JSC::GatherLiveObjFunctor::operator()):
2676         * heap/MarkedAllocator.cpp:
2677         (JSC::MarkedAllocator::allocateBlock):
2678         (JSC::MarkedAllocator::addBlock):
2679         (JSC::MarkedAllocator::reset):
2680         (JSC::MarkedAllocator::lastChanceToFinalize):
2681         (JSC::LastChanceToFinalize::operator()): Deleted.
2682         * heap/MarkedAllocator.h:
2683         (JSC::MarkedAllocator::takeLastActiveBlock):
2684         (JSC::MarkedAllocator::resumeAllocating):
2685         (JSC::MarkedAllocator::forEachBlock):
2686         * heap/MarkedBlock.cpp:
2687         (JSC::MarkedBlock::create):
2688         (JSC::MarkedBlock::destroy):
2689         (JSC::MarkedBlock::MarkedBlock):
2690         (JSC::MarkedBlock::callDestructor):
2691         (JSC::MarkedBlock::specializedSweep):
2692         (JSC::SetNewlyAllocatedFunctor::SetNewlyAllocatedFunctor):
2693         (JSC::SetNewlyAllocatedFunctor::operator()):
2694         (JSC::MarkedBlock::stopAllocating):
2695         (JSC::MarkedBlock::didRetireBlock):
2696         * heap/MarkedBlock.h:
2697         (JSC::MarkedBlock::CountFunctor::CountFunctor):
2698         (JSC::MarkedBlock::CountFunctor::count):
2699         (JSC::MarkedBlock::CountFunctor::returnValue):
2700         (JSC::MarkedBlock::needsDestruction):
2701         (JSC::MarkedBlock::cellKind):
2702         (JSC::MarkedBlock::size):
2703         (JSC::MarkedBlock::clearNewlyAllocated):
2704         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
2705         (JSC::MarkedBlock::isLive):
2706         (JSC::MarkedBlock::isLiveCell):
2707         (JSC::MarkedBlock::forEachCell):
2708         (JSC::MarkedBlock::forEachLiveCell):
2709         (JSC::MarkedBlock::forEachDeadCell):
2710         * heap/MarkedSpace.cpp:
2711         (JSC::MarkedSpace::MarkedSpace):
2712         (JSC::MarkedSpace::~MarkedSpace):
2713         (JSC::MarkedSpace::lastChanceToFinalize):
2714         (JSC::MarkedSpace::sweep):
2715         (JSC::MarkedSpace::zombifySweep):
2716         (JSC::MarkedSpace::resetAllocators):
2717         (JSC::MarkedSpace::visitWeakSets):
2718         (JSC::MarkedSpace::reapWeakSets):
2719         (JSC::MarkedSpace::forEachAllocator):
2720         (JSC::MarkedSpace::stopAllocating):
2721         (JSC::MarkedSpace::resumeAllocating):
2722         (JSC::MarkedSpace::isPagedOut):
2723         (JSC::MarkedSpace::shrink):
2724         (JSC::clearNewlyAllocatedInBlock):
2725         (JSC::MarkedSpace::clearNewlyAllocated):
2726         (JSC::MarkedSpace::clearMarks):
2727         (JSC::Free::Free): Deleted.
2728         (JSC::Free::operator()): Deleted.
2729         (JSC::FreeOrShrink::FreeOrShrink): Deleted.
2730         (JSC::FreeOrShrink::operator()): Deleted.
2731         (JSC::VisitWeakSet::VisitWeakSet): Deleted.
2732         (JSC::VisitWeakSet::operator()): Deleted.
2733         (JSC::ReapWeakSet::operator()): Deleted.
2734         (JSC::LastChanceToFinalize::operator()): Deleted.
2735         (JSC::StopAllocatingFunctor::operator()): Deleted.
2736         (JSC::ResumeAllocatingFunctor::operator()): Deleted.
2737         (JSC::ClearNewlyAllocated::operator()): Deleted.
2738         (JSC::VerifyNewlyAllocated::operator()): Deleted.
2739         * heap/MarkedSpace.h:
2740         (JSC::MarkedSpace::forEachLiveCell):
2741         (JSC::MarkedSpace::forEachDeadCell):
2742         (JSC::MarkedSpace::allocatorFor):
2743         (JSC::MarkedSpace::allocateWithDestructor):
2744         (JSC::MarkedSpace::forEachBlock):
2745         (JSC::MarkedSpace::didAddBlock):
2746         (JSC::MarkedSpace::objectCount):
2747         (JSC::MarkedSpace::size):
2748         (JSC::MarkedSpace::capacity):
2749         (JSC::ClearMarks::operator()): Deleted.
2750         (JSC::Sweep::operator()): Deleted.
2751         (JSC::ZombifySweep::operator()): Deleted.
2752         (JSC::MarkCount::operator()): Deleted.
2753         (JSC::Size::operator()): Deleted.
2754         * runtime/JSCell.h:
2755         (JSC::JSCell::zap): Deleted.
2756         (JSC::JSCell::isZapped): Deleted.
2757         * runtime/JSCellInlines.h:
2758         (JSC::allocateCell):
2759         (JSC::JSCell::isObject):
2760         (JSC::isZapped): Deleted.
2761         * runtime/JSGlobalObject.cpp:
2762         * tools/JSDollarVMPrototype.cpp:
2763         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2764         (JSC::CellAddressCheckFunctor::operator()):
2765
2766 2016-07-18  Filip Pizlo  <fpizlo@apple.com>
2767
2768         Repeatedly creating and destroying workers that enqueue DFG plans can outpace the DFG worklist, which then causes VM shutdown to stall, which then causes memory growth
2769         https://bugs.webkit.org/show_bug.cgi?id=159754
2770
2771         Reviewed by Geoffrey Garen.
2772         
2773         If you create and destroy workers at a high rate and those workers enqueue some DFG plans
2774         that are still not compiled at the time that the worker is closed, then the closed workers
2775         end up stalling in VM::~VM waiting for the DFG worklist thread to finish those plans. Since
2776         we don't actually cancel the plans, it's easy to create a situation where the workers
2777         outpace the DFG worklist, especially if you create many workers at a time and each one
2778         finishes just after enqueueing those plans.
2779         
2780         The solution is to allow VM::~VM to remove plans from the DFG worklist that are related to
2781         that VM but aren't currently being worked on. That turns out to be an easy change.
2782         
2783         I have a test that repros this, but it's quite long-running. I call it workers/bomb.html. We
2784         may want to exclude it from test runs because of how long it takes.
2785
2786         * dfg/DFGWorklist.cpp:
2787         (JSC::DFG::Worklist::removeDeadPlans):
2788         (JSC::DFG::Worklist::removeNonCompilingPlansForVM):
2789         (JSC::DFG::Worklist::queueLength):
2790         (JSC::DFG::Worklist::runThread):
2791         * dfg/DFGWorklist.h:
2792         * runtime/VM.cpp:
2793         (JSC::VM::~VM):
2794
2795 2016-07-17  Filip Pizlo  <fpizlo@apple.com>
2796
2797         Object.preventExtensions/seal/freeze makes code much slower
2798         https://bugs.webkit.org/show_bug.cgi?id=143247
2799
2800         Reviewed by Michael Saboff.
2801         
2802         This has been a huge pet peeve of mine for a long time, but I was always afraid of fixing
2803         it because I thought that it would be hard. Well, it looks like it's not hard at all.
2804         
2805         The problem is that you cannot mutate a structure that participates in transition caching.
2806         You can only clone the structure and mutate that one. But if you do this, you have to make
2807         a hard choice:
2808         
2809         1) Clone the structure without caching the transition. This is what the code did before
2810            this change. It's the most obvious choice, but it introduces an uncacheable transition
2811            that leads to an explosion of structures, which then breaks all inline caches.
2812         
2813         2) Perform one of the existing cacheable transitions. Cacheable transitions can either add
2814            properties or they can do one of the NonPropertyTransitions, which until now have been
2815            restricted to just IndexingType transitions. So, only adding transitions or making
2816            certain prescribed changes to the indexing type count as cacheable transitions.
2817         
2818         This change decouples NonPropertyTransition from IndexingType and adds three new kinds of
2819         transitions: PreventExtensions, Seal, and Freeze. We have to give any cacheable transition
2820         a name that fully disambiguates this transition from any other, so that the transition can
2821         be cached. Since we're already giving them names in an enum, I figured that the most
2822         pragmatic way to implement them is to have Structure::nonPropertyTransition() case on the
2823         NonPropertyTransition and implement all of the mutations associated with that transition.
2824         The alternative would have been to allow callers of nonPropertyTransition() to supply
2825         something like a lambda that describes the mutation, but this seemed awkward since each
2826         set of mutations has to anyway be tied to one of the NonPropertyTransition members.
2827         
2828         This is an enormous speed-up on microbenchmarks that use Object.preventExtensions(),
2829         Object.seal(), or Object.freeze(). I don't know if "real" benchmarks use these features
2830         and I don't really care. This should be fast.
2831
2832         * runtime/JSObject.cpp:
2833         (JSC::JSObject::notifyPresenceOfIndexedAccessors):
2834         (JSC::JSObject::createInitialUndecided):
2835         (JSC::JSObject::createInitialInt32):
2836         (JSC::JSObject::createInitialDouble):
2837         (JSC::JSObject::createInitialContiguous):
2838         (JSC::JSObject::convertUndecidedToInt32):
2839         (JSC::JSObject::convertUndecidedToDouble):
2840         (JSC::JSObject::convertUndecidedToContiguous):
2841         (JSC::JSObject::convertInt32ToDouble):
2842         (JSC::JSObject::convertInt32ToContiguous):
2843         (JSC::JSObject::convertDoubleToContiguous):
2844         (JSC::JSObject::switchToSlowPutArrayStorage):
2845         * runtime/Structure.cpp:
2846         (JSC::Structure::suggestedArrayStorageTransition):
2847         (JSC::Structure::addPropertyTransition):
2848         (JSC::Structure::toUncacheableDictionaryTransition):
2849         (JSC::Structure::sealTransition):
2850         (JSC::Structure::freezeTransition):
2851         (JSC::Structure::preventExtensionsTransition):
2852         (JSC::Structure::takePropertyTableOrCloneIfPinned):
2853         (JSC::Structure::nonPropertyTransition):
2854         (JSC::Structure::pin):
2855         (JSC::Structure::pinForCaching):
2856         (JSC::Structure::allocateRareData):
2857         * runtime/Structure.h:
2858         * runtime/StructureTransitionTable.h:
2859         (JSC::toAttributes):
2860         (JSC::changesIndexingType):
2861         (JSC::newIndexingType):
2862         (JSC::preventsExtensions):
2863         (JSC::setsDontDeleteOnAllProperties):
2864         (JSC::setsReadOnlyOnAllProperties):
2865
2866 2016-07-17  Filip Pizlo  <fpizlo@apple.com>
2867
2868         RegisterSet should use a Bitmap instead of a BitVector so that it never allocates memory and is trivial to copy
2869         https://bugs.webkit.org/show_bug.cgi?id=159863
2870
2871         Reviewed by Saam Barati.
2872         
2873         Switch RegisterSet set to Bitmap because Bitmap doesn't ever allocate memory and can be
2874         assigned by memcpy. This should be a performance improvement for compiler code that does a
2875         lot of things with RegisterSet. For example, it's one of the fundamental data structures in
2876         Air. The previous use of BitVector meant that almost every operation on RegisterSet would
2877         have a slow path call. On ARM64, it would mean memory allocation for any RegisterSet that
2878         used all available registers.
2879         
2880         This meant adding even more GPR/FPR reflection to the MacroAssembler API: we now have consts
2881         called numGPRs and numFPRs. This is necessary to statically size the Bitmap in RegisterSet.
2882         
2883         Here's the breakdown of sizes of RegisterSet on different CPUs:
2884         
2885         x86-32: 8 bits (GPRs) + 8 bits (FPRs) + 1 bit (is deleted) = 1x uint32_t.
2886         x86-64: 16 bits + 16 bits + 1 bit = 2x uint32_t.
2887         ARMv7: 16 bits + 16 bits + 1 bit = 2x uint32_t.
2888         ARM64: 32 bits + 32 bits + 1 bit = 3x uint32_t.
2889
2890         * assembler/MacroAssemblerARM.h:
2891         * assembler/MacroAssemblerARM64.h:
2892         * assembler/MacroAssemblerARMv7.h:
2893         * assembler/MacroAssemblerX86.h:
2894         * assembler/MacroAssemblerX86Common.h:
2895         (JSC::MacroAssemblerX86Common::scratchRegister):
2896         * assembler/MacroAssemblerX86_64.h:
2897         * jit/RegisterSet.h:
2898         (JSC::RegisterSet::set):
2899         (JSC::RegisterSet::get):
2900         (JSC::RegisterSet::setAll):
2901         (JSC::RegisterSet::merge):
2902         (JSC::RegisterSet::filter):
2903         (JSC::RegisterSet::exclude):
2904         (JSC::RegisterSet::numberOfSetRegisters):
2905         (JSC::RegisterSet::RegisterSet):
2906         (JSC::RegisterSet::isEmptyValue):
2907         (JSC::RegisterSet::isDeletedValue):
2908         (JSC::RegisterSet::operator==):
2909         (JSC::RegisterSet::operator!=):
2910         (JSC::RegisterSet::hash):
2911         (JSC::RegisterSet::forEach):
2912         (JSC::RegisterSet::setMany):
2913
2914 2016-07-15  Filip Pizlo  <fpizlo@apple.com>
2915
2916         DFG and FTL should support op_call_eval
2917         https://bugs.webkit.org/show_bug.cgi?id=159786
2918
2919         Reviewed by Saam Barati.
2920         
2921         This adds support for op_call_eval in DFG and FTL by brute force:
2922         
2923         - There is now a CallEval() node type, which compiles exactly the same way that we do in
2924           baseline.
2925         
2926         - We teach the DFG and bytecode liveness that the scope register and 'this' are read by
2927           CallEval()/op_call_eval.
2928         
2929         We can compile eval quite well, except that right now we cannot inline functions that use
2930         eval. It would be nice to do that, but the payoff is probably smaller. "Don't inline users
2931         of eval" may even be an OK inlining heuristic. Not inlining users of eval allows me to
2932         reuse the baseline implementation, which is really great. Otherwise, I'd have to get rid
2933         of things like the rogue reads of scope register and 'this'.
2934         
2935         The goal here is to produce speed-ups for code that has functions that do both eval and
2936         some computational stuff. Obviously, we're not producing any benefit for the eval itself.
2937         But now the other stuff in a function that uses eval will get to participate in
2938         optimization.
2939         
2940         This is a huge speed-up on microbenchmarks.
2941
2942         * bytecode/BytecodeUseDef.h:
2943         (JSC::computeUsesForBytecodeOffset):
2944         * bytecode/CodeBlock.cpp:
2945         (JSC::CodeBlock::printCallOp):
2946         (JSC::CodeBlock::dumpBytecode):
2947         * dfg/DFGAbstractInterpreterInlines.h:
2948         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2949         * dfg/DFGByteCodeParser.cpp:
2950         (JSC::DFG::ByteCodeParser::setLocal):
2951         (JSC::DFG::ByteCodeParser::setArgument):
2952         (JSC::DFG::ByteCodeParser::flush):
2953         (JSC::DFG::ByteCodeParser::parseBlock):
2954         * dfg/DFGCapabilities.cpp:
2955         (JSC::DFG::capabilityLevel):
2956         * dfg/DFGClobberize.h:
2957         (JSC::DFG::clobberize):
2958         * dfg/DFGDoesGC.cpp:
2959         (JSC::DFG::doesGC):
2960         * dfg/DFGFixupPhase.cpp:
2961         (JSC::DFG::FixupPhase::fixupNode):
2962         * dfg/DFGGraph.h:
2963         (JSC::DFG::Graph::needsScopeRegister):
2964         (JSC::DFG::Graph::needsFlushedThis):
2965         * dfg/DFGHeapLocation.cpp:
2966         (WTF::printInternal):
2967         * dfg/DFGHeapLocation.h:
2968         * dfg/DFGMayExit.cpp:
2969         * dfg/DFGNode.h:
2970         (JSC::DFG::Node::hasHeapPrediction):
2971         * dfg/DFGNodeType.h:
2972         * dfg/DFGOSRExitCompiler.cpp:
2973         * dfg/DFGPredictionPropagationPhase.cpp:
2974         * dfg/DFGSafeToExecute.h:
2975         (JSC::DFG::safeToExecute):
2976         * dfg/DFGSpeculativeJIT32_64.cpp:
2977         (JSC::DFG::SpeculativeJIT::emitCall):
2978         (JSC::DFG::SpeculativeJIT::compile):
2979         * dfg/DFGSpeculativeJIT64.cpp:
2980         (JSC::DFG::SpeculativeJIT::emitCall):
2981         (JSC::DFG::SpeculativeJIT::compile):
2982         * dfg/DFGStackLayoutPhase.cpp:
2983         (JSC::DFG::StackLayoutPhase::run):
2984         * dfg/DFGWatchpointCollectionPhase.cpp:
2985         (JSC::DFG::WatchpointCollectionPhase::handle):
2986         * ftl/FTLCapabilities.cpp:
2987         (JSC::FTL::canCompile):
2988         * ftl/FTLCompile.cpp:
2989         (JSC::FTL::compile):
2990         * ftl/FTLLowerDFGToB3.cpp:
2991         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2992         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
2993         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
2994         (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
2995         * jit/AssemblyHelpers.cpp:
2996         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
2997         (JSC::AssemblyHelpers::emitDumbVirtualCall):
2998         * jit/AssemblyHelpers.h:
2999         (JSC::AssemblyHelpers::emitTypeOf):
3000         * jit/JITCall.cpp:
3001         (JSC::JIT::compileCallEvalSlowCase):
3002         * jit/JITCall32_64.cpp:
3003         (JSC::JIT::compileCallEvalSlowCase):
3004         * jit/JITOperations.cpp:
3005         * tests/stress/exit-then-eval.js: Added.
3006         (foo):
3007         * tests/stress/force-exit-then-eval-dfg.js: Added.
3008         (foo):
3009         * tests/stress/force-exit-then-eval.js: Added.
3010         (foo):
3011
3012 2016-07-12  Filip Pizlo  <fpizlo@apple.com>
3013
3014         DFG should really support jneq_ptr
3015         https://bugs.webkit.org/show_bug.cgi?id=159700
3016
3017         Reviewed by Keith Miller.
3018         
3019         Prior to this change, DFG statically speculated that jneq_ptr would always fall through. This
3020         meant that programs that called o.apply() or o.call() where apply or call weren't the
3021         expected ones (i.e. the function.prototype.apply/call) would rage-recompile forever.
3022         
3023         This adds profiling to jneq_ptr. We now know if it always falls through or sometimes doesn't.
3024         If it sometimes doesn't, we now emit an actual control flow diamond. I decided to add a new
3025         NodeType for "equal pointer", since none of the existing ones really captured that. For
3026         example, there was no way to express "equal pointer" for strings or symbols. We don't use it
3027         for that right now, but we might, and if we did, then it would be hugely surprising that the
3028         DFG interpreted this as value equality. So, the DFG now has CompareEqPtr, which means exactly
3029         what jneq_ptr means by "equal pointer".
3030         
3031         This is an enormous speed-up on microbenchmarks. I would assume that it's a speed-up on some
3032         real things, too, but I don't know that for a fact.
3033
3034         * bytecode/BytecodeList.json:
3035         * bytecode/CodeBlock.cpp:
3036         (JSC::CodeBlock::dumpBytecode):
3037         * bytecompiler/BytecodeGenerator.cpp:
3038         (JSC::BytecodeGenerator::emitJumpIfNotFunctionCall):
3039         (JSC::BytecodeGenerator::emitJumpIfNotFunctionApply):
3040         (JSC::BytecodeGenerator::emitExpectedFunctionSnippet):
3041         * dfg/DFGAbstractInterpreterInlines.h:
3042         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3043         * dfg/DFGByteCodeParser.cpp:
3044         (JSC::DFG::ByteCodeParser::parseBlock):
3045         * dfg/DFGClobberize.h:
3046         (JSC::DFG::clobberize):
3047         * dfg/DFGDoesGC.cpp:
3048         (JSC::DFG::doesGC):
3049         * dfg/DFGFixupPhase.cpp:
3050         (JSC::DFG::FixupPhase::fixupNode):
3051         * dfg/DFGNode.h:
3052         (JSC::DFG::Node::hasCellOperand):
3053         * dfg/DFGNodeType.h:
3054         * dfg/DFGSafeToExecute.h:
3055         (JSC::DFG::safeToExecute):
3056         * dfg/DFGSpeculativeJIT.cpp:
3057         (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
3058         (JSC::DFG::SpeculativeJIT::compileCompareEqPtr):
3059         * dfg/DFGSpeculativeJIT.h:
3060         * dfg/DFGSpeculativeJIT32_64.cpp:
3061         (JSC::DFG::SpeculativeJIT::compile):
3062         * dfg/DFGSpeculativeJIT64.cpp:
3063         (JSC::DFG::SpeculativeJIT::compile):
3064         * dfg/DFGValidate.cpp:
3065         * ftl/FTLCapabilities.cpp:
3066         (JSC::FTL::canCompile):
3067         * ftl/FTLLowerDFGToB3.cpp:
3068         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3069         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
3070         (JSC::FTL::DFG::LowerDFGToB3::compileCompareEqPtr):
3071         (JSC::FTL::DFG::LowerDFGToB3::compileCompareLess):
3072         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEqConstant): Deleted.
3073         * jit/JITOpcodes.cpp:
3074         (JSC::JIT::emit_op_jneq_ptr):
3075         (JSC::JIT::emit_op_eq):
3076         * jit/JITOpcodes32_64.cpp:
3077         (JSC::JIT::emit_op_jneq_ptr):
3078         (JSC::JIT::emit_op_eq):
3079         * llint/LowLevelInterpreter32_64.asm:
3080         * llint/LowLevelInterpreter64.asm:
3081
3082 2016-07-12  Filip Pizlo  <fpizlo@apple.com>
3083
3084         OSR entry into DFG has problems with lexical scoping
3085         https://bugs.webkit.org/show_bug.cgi?id=159687
3086
3087         Reviewed by Saam Barati.
3088         
3089         What a fun bug! It turns out that uses of lexical scoping, like "let", may sometimes cause us
3090         to not be able to OSR enter into a loop from baseline to DFG. The bug is in a mitigation for
3091         a different bug, which in turn had a mitigation for yet another bug, so the story here is a
3092         long one.
3093         
3094         DFG OSR entry has long had a mitigation for the following bug: the DFG bytecode parser may
3095         choose to make us always OSR exit at some instruction if it thinks that it doesn't have
3096         enough profiling for that instruction. We will do this if some kinds of put_by_id only
3097         execute once, for example. This causes problems for loopy benchmarks like this:
3098         
3099             put_by_id(something crazy);
3100             for (var i = 0; i < bigNumber; ++i) simpleMath;
3101         
3102         In this case, the put_by_id will have only executed once, and since it did something crazy
3103         that one time, the bytecode parser will replace it with ForceOSRExit.
3104         
3105         This creates an OSR entry bug: DFG CFA will then prove that the loop is unreachable, and will
3106         tell OSR entry that it's impossible to enter into that loop.
3107         
3108         We mitigated this bug a long time ago by recording mustHandleValues for loops at which we
3109         want to enter. We inject these values into DFG CFA and we force CFA to recognize that the
3110         loop is reachable even if CFA wanted to prove that it wasn't.
3111         
3112         But this leads to another bug: we need to scrape the values from the stack inside
3113         operationOptimize() and then we need to reason about them in the compiler. Some of those
3114         values may be garbage, which would cause pandemonium inside the compiler. We also mitigated
3115         this bug, by only recording the "vars", since those are guaranteed to be reset by op_enter.
3116         
3117         And that's where the lexical scoping bug happens: "let" bound variables aren't part of the
3118         "vars". DFG will see that they are live, but mustHandleValues will not have anything for
3119         those variables, so CFA will prove that the values are Bottom. Then OSR entry will always
3120         fail because no value is ever a subset of Bottom.
3121         
3122         The first part of the fix is to ensure that mustHandleValues record all of the values on the
3123         stack (i.e. within m_numCalleeLocals, rather than just m_numVars). But this creates a second
3124         problem: we may record garbage. This patch includes a better fix for the garbage: before
3125         touching mustHandleValues we run the bytecode liveness analysis and clear any values that are
3126         not live. This ensures that we clear the garbage.
3127         
3128         This is an enormous speed-up on microbenchmarks that use lexical scoping and have some crazy
3129         put_by_id in the lead-up to the hot loop.
3130
3131         * dfg/DFGCFAPhase.cpp:
3132         (JSC::DFG::CFAPhase::run):
3133         * dfg/DFGOSREntry.cpp:
3134         (JSC::DFG::prepareOSREntry):
3135         * dfg/DFGPlan.cpp:
3136         (JSC::DFG::Plan::compileInThreadImpl):
3137         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
3138         (JSC::DFG::Plan::cancel):
3139         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
3140         * dfg/DFGPlan.h:
3141         (JSC::DFG::Plan::canTierUpAndOSREnter):
3142         * jit/JITOperations.cpp:
3143
3144 2016-07-18  Youenn Fablet  <youenn@apple.com>
3145
3146         REGRESSION(r202975): --minimal build is broken
3147         https://bugs.webkit.org/show_bug.cgi?id=159765
3148
3149         Reviewed by Chris Dumez.
3150
3151         Covered partially by builtin generated test code.
3152
3153         Updating generator to add a global compilation guard around the code that generates all global internal properties.
3154         Split the generate_methods function in two, one dedicated to the visit method and the second one dedicated to
3155         the initialize method.
3156
3157         * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
3158         (BuiltinsInternalsWrapperImplementationGenerator.generate_section_for_object): Use splitted generation functions.
3159         (BuiltinsInternalsWrapperImplementationGenerator.generate_visit_method): Response to generate the visit method.
3160         (BuiltinsInternalsWrapperImplementationGenerator._generate_initialize_static_globals): Responsible to generate
3161         the code to initialize the internal globals. This code is put in a global compilation guard in case all
3162         internals are compiled out by specific builds.
3163         (BuiltinsInternalsWrapperImplementationGenerator):
3164         (BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method): Responsible to generate the
3165         initialize method.
3166         (BuiltinsInternalsWrapperImplementationGenerator.generate_methods): Deleted.
3167         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Copyright change.
3168         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
3169         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
3170         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
3171         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Reflects partially the built-in
3172         generator change.
3173
3174 2016-07-18  Keith Miller  <keith_miller@apple.com>
3175
3176         Fix bad assertions in genericTypedArrayViewPrivateFuncSubarrayCreate
3177         https://bugs.webkit.org/show_bug.cgi?id=159882
3178         <rdar://problem/27327111>
3179
3180         Reviewed by Mark Lam.
3181
3182         According the spec toInteger can return values we don't consider ints.
3183         Such as, -0 and +/-Infinity. This broke some assertions in
3184         genericTypedArrayViewPrivateFuncSubarrayCreate.
3185
3186         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
3187         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
3188         * tests/stress/typedarray-subarray.js:
3189
3190 2016-07-16  Filip Pizlo  <fpizlo@apple.com>
3191
3192         DFG CSE is broken for MultiGetByOffset
3193         https://bugs.webkit.org/show_bug.cgi?id=159858
3194
3195         Reviewed by Saam Barati.
3196         
3197         This disabled CSE for MultiGetByOffset. I opened bug 159859 for the long-term fix, which
3198         would teach CSE (and other passes also) how to decay a removed MultiGetByOffset to a
3199         CheckStructure. Since we currently just decay MultiGetByOffset to Check, we forget the
3200         structure checks. So, if we CSE a MultiGetByOffset that checks for one set of structures with
3201         a heap access on the same property and base that checks for different structures, then we
3202         will forget some structure checks that we had previously. It's unsound to forget checks in
3203         DFG IR.
3204         
3205         This bug mostly manifested as a high-volume crash at Unreachable in FTL, because we'd prove
3206         that the code after the MultiGetByOffset was unreachable due to the structure checks and then
3207         CSE would remove everything but the Unreachable.
3208
3209         * dfg/DFGClobberize.h:
3210         (JSC::DFG::clobberize): Remove the def() for MultiGetByOffset to disable CSE for this node for now.
3211         * tests/stress/cse-multi-get-by-offset-remove-checks.js: Added. This used to fail with FTL enabled.
3212         (Cons1):
3213         (Cons2):
3214         (Cons3):
3215         (foo):
3216         (bar):
3217
3218 2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3219
3220         [JSC] Enable test262 module tests
3221         https://bugs.webkit.org/show_bug.cgi?id=159854
3222
3223         Reviewed by Saam Barati.
3224
3225         This patch enables test262 module tests. Before this patch, the modules tests in test262 do not work fine.
3226         This patch fixes the following 2 things.
3227
3228         1. Test harness
3229
3230             Before this patch, there is only one global switch "-m" in jsc shell. So we cannot load the test262 test harness before evaluating the module tests.
3231             This patch adds a new option, "--module-file=". It is similar to "--strict-file=". When we specify the file with "--module-file=", it is evaluated as
3232             a module, while the other files are evaluated by following the JSC's default manner. This option allows us to load the test harness files into the
3233             global context before loading the module tests.
3234
3235         2. Module's asynchronous errors
3236
3237             Before this patch, the errors caused in the module evaluation are not handled as the same to the usual sync files. In synchronous execution, we have
3238             "--exception=" option to pass the expected exception to the JSC shell. But this option does not work in the module evaluation.
3239             This patch correctly handles this expected exception in the module evaluation promise's fulfill and reject handlers.
3240
3241         And we fix the YAML file. Now the recorded :fail and :normal are the correct test results for the module tests.
3242
3243         * jsc.cpp:
3244         (Script::Script):
3245         (checkUncaughtException):
3246         (runWithScripts):
3247         (printUsageStatement):
3248         (CommandLine::parseArguments):
3249         (dumpException): Deleted.
3250         * tests/test262.yaml:
3251
3252 2016-07-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3253
3254         [JSC] Mask TrustedImm32 to 8bit in MacroAssembler for 8bit operations
3255         https://bugs.webkit.org/show_bug.cgi?id=159334
3256
3257         Reviewed by Filip Pizlo.
3258
3259         Previously, in 8bit operations (like add8, compare8, test8, branch8, branchTest8 etc.),
3260         we require that the given TrustedImm32 is in range of 8bit. While achieving this in
3261         the manual MacroAssembler calling is easy, in Air, we don't guarantee that the higher bit
3262         of the 8bit argument is cleared. So the current assertions are invalid.
3263