10e6b6160d279e48c91da7cb93845e55df8f80a2
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [JSC][GTK] glib RunLoop does not accept negative start interval
4         https://bugs.webkit.org/show_bug.cgi?id=170775
5
6         Reviewed by Saam Barati.
7
8         * heap/GCActivityCallback.cpp:
9         (JSC::GCActivityCallback::scheduleTimer):
10
11 2017-04-17  Saam Barati  <sbarati@apple.com>
12
13         BytecodeGenerator ".call" and ".apply" is exponential in nesting depth
14         https://bugs.webkit.org/show_bug.cgi?id=139847
15         <rdar://problem/19321122>
16
17         Reviewed by Oliver Hunt.
18
19         The BytecodeGenerator's .apply(...) and .call(...) code would
20         emit bytecode for the evaluation of its arguments twice. This
21         is exponential, specifically, 2^n, where n is the nesting depth of
22         .call(...) or .apply(...) inside other .call(...) or .apply(...).
23         
24         The reason we emit code for the arguments twice is that we try
25         to emit efficient code for when .call or .apply is Function.prototype.call
26         or Function.prototype.apply. Because of this, we compare .call/.apply to
27         Function.prototype.call/.apply, and if they're the same, we emit a specialized
28         function call in bytecode. Otherwise, we emit the generalized version.
29         
30         This patch makes it so that each .call(...) and .apply(...) records
31         its max inner nesting depth. Then, we only perform the optimization
32         for the bottom k (where k = 6) layers of the nesting tree. The reason we
33         apply the optimization to the bottom k layers instead of top k layers
34         is that we'll produce less code this way.
35
36         * bytecompiler/NodesCodegen.cpp:
37         (JSC::CallFunctionCallDotNode::emitBytecode):
38         (JSC::ApplyFunctionCallDotNode::emitBytecode):
39         * parser/ASTBuilder.h:
40         (JSC::ASTBuilder::makeFunctionCallNode):
41         * parser/NodeConstructors.h:
42         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
43         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
44         * parser/Nodes.h:
45         * parser/Parser.cpp:
46         (JSC::recordCallOrApplyDepth):
47         (JSC::Parser<LexerType>::parseMemberExpression):
48         * parser/Parser.h:
49         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth):
50         (JSC::Parser::CallOrApplyDepth::maxChildDepth):
51         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth):
52         * parser/SyntaxChecker.h:
53         (JSC::SyntaxChecker::makeFunctionCallNode):
54
55 2017-04-17  Mark Lam  <mark.lam@apple.com>
56
57         JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
58         https://bugs.webkit.org/show_bug.cgi?id=170896
59         <rdar://problem/31651319>
60
61         Reviewed by JF Bastien and Keith Miller.
62
63         * runtime/JSArray.cpp:
64         (JSC::JSArray::appendMemcpy):
65
66 2017-04-17  Joseph Pecoraro  <pecoraro@apple.com>
67
68         Web Inspector: Doesn't show size of compressed content correctly
69         https://bugs.webkit.org/show_bug.cgi?id=155112
70         <rdar://problem/25006728>
71
72         Reviewed by Alex Christensen and Timothy Hatcher.
73
74         * inspector/protocol/Network.json:
75         New, exact size metrics, available after the load completes.
76
77 2017-04-17  Youenn Fablet  <youenn@apple.com>
78
79         Disable outdated WritableStream API
80         https://bugs.webkit.org/show_bug.cgi?id=170749
81         <rdar://problem/31446233>
82
83         Reviewed by Alex Christensen.
84
85         * Configurations/FeatureDefines.xcconfig:
86
87 2017-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
88
89         [JSCOnly] Fix build failures in macOS
90         https://bugs.webkit.org/show_bug.cgi?id=170887
91
92         Reviewed by Alex Christensen.
93
94         Align ICU header configuration to MacCMake port.
95
96         * PlatformJSCOnly.cmake:
97
98 2017-04-17  JF Bastien  <jfbastien@apple.com>
99
100         B3: don't allow unsigned offsets in Value
101         https://bugs.webkit.org/show_bug.cgi?id=170692
102
103         Reviewed by Filip Pizlo.
104
105         MemoryValue and similar B3 opcode classes always expects a signed
106         offset. Giving it an out-of-bounds unsigned offset causes
107         implementation-defined behavior, which can cause badness as I just
108         fixed in WebAssembly.  This patch makes it impossible to create a
109         Value opcodes with an unsigned value, or with an overly-large
110         value.
111
112         * b3/B3AtomicValue.cpp:
113         (JSC::B3::AtomicValue::AtomicValue):
114         * b3/B3AtomicValue.h:
115         * b3/B3Common.h:
116         (JSC::B3::isRepresentableAs):
117         * b3/B3EliminateCommonSubexpressions.cpp:
118         * b3/B3LowerToAir.cpp:
119         (JSC::B3::Air::LowerToAir::scaleForShl):
120         (JSC::B3::Air::LowerToAir::effectiveAddr):
121         (JSC::B3::Air::LowerToAir::addr):
122         (JSC::B3::Air::LowerToAir::tryAppendLea):
123         * b3/B3MemoryValue.cpp:
124         (JSC::B3::MemoryValue::isLegalOffsetImpl):
125         (JSC::B3::MemoryValue::MemoryValue):
126         * b3/B3MemoryValue.h:
127         * b3/B3MemoryValueInlines.h:
128         (JSC::B3::MemoryValue::isLegalOffsetImpl):
129         * b3/B3MoveConstants.cpp:
130         * b3/B3ReduceStrength.cpp:
131         * b3/B3StackmapSpecial.cpp:
132         (JSC::B3::StackmapSpecial::repForArg):
133         * b3/B3Value.h:
134         * b3/air/AirArg.cpp:
135         (JSC::B3::Air::Arg::stackAddrImpl):
136         * b3/air/AirArg.h:
137         (JSC::B3::Air::Arg::addr):
138         (JSC::B3::Air::Arg::stack):
139         (JSC::B3::Air::Arg::callArg):
140         (JSC::B3::Air::Arg::stackAddr):
141         (JSC::B3::Air::Arg::index):
142         (JSC::B3::Air::Arg::offset):
143         (JSC::B3::Air::Arg::isValidAddrForm):
144         (JSC::B3::Air::Arg::isValidIndexForm):
145         (JSC::B3::Air::Arg::asTrustedImm32):
146         (JSC::B3::Air::Arg::asAddress):
147         (JSC::B3::Air::Arg::asBaseIndex):
148         * b3/air/AirLowerStackArgs.cpp:
149         (JSC::B3::Air::lowerStackArgs):
150         * b3/testb3.cpp:
151         (JSC::B3::testMulArgStore):
152         (JSC::B3::testStore32):
153         (JSC::B3::testStoreConstant):
154         (JSC::B3::testStoreConstantPtr):
155         (JSC::B3::testStoreAddLoad32):
156         (JSC::B3::testStoreAddLoadImm32):
157         (JSC::B3::testStoreAddLoad8):
158         (JSC::B3::testStoreAddLoadImm8):
159         (JSC::B3::testStoreAddLoad16):
160         (JSC::B3::testStoreAddLoadImm16):
161         (JSC::B3::testStoreAddLoad64):
162         (JSC::B3::testStoreAddLoadImm64):
163         (JSC::B3::testStoreAddLoad32Index):
164         (JSC::B3::testStoreAddLoadImm32Index):
165         (JSC::B3::testStoreAddLoad64Index):
166         (JSC::B3::testStoreAddLoadImm64Index):
167         (JSC::B3::testStoreSubLoad):
168         (JSC::B3::testStoreAddLoadInterference):
169         (JSC::B3::testStoreAddAndLoad):
170         (JSC::B3::testStoreNegLoad32):
171         (JSC::B3::testStoreNegLoadPtr):
172         (JSC::B3::testLoadOffset):
173         (JSC::B3::testLoadOffsetNotConstant):
174         (JSC::B3::testLoadOffsetUsingAdd):
175         (JSC::B3::testLoadOffsetUsingAddInterference):
176         (JSC::B3::testLoadOffsetUsingAddNotConstant):
177         (JSC::B3::testStoreLoadStackSlot):
178         (JSC::B3::testLoad):
179         (JSC::B3::testInterpreter):
180         (JSC::B3::testTrappingStore):
181         (JSC::B3::testTrappingLoadAddStore):
182         (JSC::B3::testWasmAddress):
183         * wasm/WasmB3IRGenerator.cpp:
184         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
185         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
186         (JSC::Wasm::B3IRGenerator::emitLoadOp):
187         (JSC::Wasm::B3IRGenerator::emitStoreOp):
188
189 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
190
191         test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js
192         https://bugs.webkit.org/show_bug.cgi?id=170882
193
194         Reviewed by Saam Barati.
195
196         * runtime/ObjectPrototype.cpp:
197         (JSC::objectProtoFuncToLocaleString):
198         We should be using the this value without ToObject conversion both when
199         getting the potential accessor and calling it. In strict mode, the this
200         value will remain its simple value, in non-strict it is still converted.
201
202 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
203
204         test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js
205         https://bugs.webkit.org/show_bug.cgi?id=170888
206
207         Reviewed by Saam Barati.
208
209         * runtime/ExceptionHelpers.h:
210         * runtime/ExceptionHelpers.cpp:
211         (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction):
212         Fix up this function name.
213
214         * runtime/JSObject.cpp:
215         (JSC::callToPrimitiveFunction):
216         When called with @@isPrimitive, bail on undefined or null and
217         throw a type error if the value is not callable.
218
219         (JSC::JSObject::toPrimitive):
220         Use throw scope to check for exception.
221
222 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
223
224         test262: test262/test/language/expressions/tagged-template/template-object.js
225         https://bugs.webkit.org/show_bug.cgi?id=170878
226
227         Reviewed by Saam Barati.
228
229         * runtime/JSArray.cpp:
230         (JSC::JSArray::put):
231         The fast path for setting an Array's length should check if length is
232         writable before checking for and possibly throwing a RangeError.
233
234 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
235
236         test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js
237         https://bugs.webkit.org/show_bug.cgi?id=170879
238
239         Reviewed by Saam Barati.
240
241         * runtime/StringObject.h:
242         * runtime/StringObject.cpp:
243         (JSC::StringObject::getOwnPropertyNames):
244         (JSC::StringObject::getOwnNonIndexPropertyNames):
245         Ensure 'length' comes after all indexed properties by moving
246         it out to the getOwnNonIndexPropertyNames method which is called
247         inside of getOwnPropertyNames after JSObject handles indices.
248
249 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
250
251         test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js
252         https://bugs.webkit.org/show_bug.cgi?id=170884
253
254         Reviewed by Yusuke Suzuki.
255
256         * runtime/DatePrototype.cpp:
257         (JSC::DatePrototype::finishCreation):
258         * runtime/FunctionPrototype.cpp:
259         (JSC::FunctionPrototype::addFunctionProperties):
260         * runtime/RegExpPrototype.cpp:
261         (JSC::RegExpPrototype::finishCreation):
262         * runtime/SymbolPrototype.cpp:
263         (JSC::SymbolPrototype::finishCreation):
264         Give symbol property functions proper function names.
265         This addresses function.name but not function.toString().
266
267 2017-04-15  Joseph Pecoraro  <pecoraro@apple.com>
268
269         test262: test262/test/language/global-code/new.target-arrow.js
270         https://bugs.webkit.org/show_bug.cgi?id=170872
271
272         Reviewed by Saam Barati.
273
274         * parser/Parser.cpp:
275         (JSC::Parser<LexerType>::Parser):
276         Mark the global code scope.
277
278         (JSC::Parser<LexerType>::parseMemberExpression):
279         If new.target is detected in an arrow function defined in global scope
280         throw a SyntaxError.
281
282         * parser/Parser.h:
283         (JSC::Scope::Scope):
284         (JSC::Scope::setIsGlobalCodeScope):
285         (JSC::Scope::isGlobalCodeScope):
286         Marker for a global code scope.
287
288         * parser/ParserModes.h:
289         (JSC::isModuleParseMode):
290         (JSC::isProgramParseMode):
291         (JSC::isProgramOrModuleParseMode):
292         Helper for detecting global code based on parse mode.
293
294 2017-04-14  Nikita Vasilyev  <nvasilyev@apple.com>
295
296         Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly
297         https://bugs.webkit.org/show_bug.cgi?id=170760
298
299         Reviewed by Joseph Pecoraro.
300
301         Add payloadLength property, which is used to display size. When payloadLength is unavailable,
302         it is calculated from payloadData by Web Inspector frontend.
303
304         This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect.
305
306         * inspector/protocol/Network.json:
307
308 2017-04-14  Saam Barati  <sbarati@apple.com>
309
310         ParseInt intrinsic in DFG backend doesn't properly flush its operands
311         https://bugs.webkit.org/show_bug.cgi?id=170865
312
313         Reviewed by Mark Lam and Geoffrey Garen.
314
315         The DFG backend code needed to first call .gpr()/.jsValueRegs()
316         before calling flushRegisters(), or the input JSValueOperand would
317         not be flushed.
318
319         * dfg/DFGSpeculativeJIT.cpp:
320         (JSC::DFG::SpeculativeJIT::compileParseInt):
321
322 2017-04-14  Mark Lam  <mark.lam@apple.com>
323
324         Update architectures in xcconfig files.
325         https://bugs.webkit.org/show_bug.cgi?id=170867
326         <rdar://problem/31628104>
327
328         Reviewed by Joseph Pecoraro.
329
330         * Configurations/Base.xcconfig:
331         * Configurations/FeatureDefines.xcconfig:
332         * Configurations/JavaScriptCore.xcconfig:
333         * Configurations/ToolExecutable.xcconfig:
334
335 2017-04-14  Keith Miller  <keith_miller@apple.com>
336
337         WebAssembly: B3IRGenerator should use phis for result types
338         https://bugs.webkit.org/show_bug.cgi?id=170863
339
340         Reviewed by Filip Pizlo.
341
342         Currently, we use variables for the result types of control flow in
343         Wasm. We did this originally since we weren't sure that the phis we
344         generated would be optimal. Since then, we have verified that the edges
345         in wasm control flow ensure that each upsilon will dominate its phi
346         so we don't need to use variables.
347
348         * wasm/WasmB3IRGenerator.cpp:
349         (JSC::Wasm::B3IRGenerator::ControlData::ControlData):
350         (JSC::Wasm::B3IRGenerator::addTopLevel):
351         (JSC::Wasm::B3IRGenerator::addBlock):
352         (JSC::Wasm::B3IRGenerator::addLoop):
353         (JSC::Wasm::B3IRGenerator::unify):
354
355 2017-04-14  Alex Christensen  <achristensen@webkit.org>
356
357         Fix Windows build after r215368.
358         https://bugs.webkit.org/show_bug.cgi?id=170641
359
360         * CMakeLists.txt:
361         Add new directory containing files needed in WebCore.
362
363 2017-04-14  Caitlin Potter  <caitp@igalia.com>
364
365         [JSC] use ExpressionErrorClassifier for AwaitExpression operand
366         https://bugs.webkit.org/show_bug.cgi?id=170844
367
368         Reviewed by Saam Barati.
369
370         In parseAssignmentExpression(), several cover grammars are handled, and
371         use ExpressionErrorClassifier to record hints about which grammars to
372         try.
373
374         In parseAwaitExpression(), the hints recorded during parsing of the
375         operand need to be discarded, because if they propagate to the outer
376         parseAssignmentExpression(), the hints will lead the parser down invalid
377         branches that should be skipped.
378
379         This change adds an additional ExpressionErrorClassifier to
380         parseAwaitExpression(), in order to discard hints recorded trying to
381         parse the operand.
382
383         * parser/Parser.cpp:
384         (JSC::Parser<LexerType>::parseAwaitExpression):
385
386 2017-04-14  Saam Barati  <sbarati@apple.com>
387
388         WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called
389         https://bugs.webkit.org/show_bug.cgi?id=170641
390
391         Reviewed by Keith Miller.
392
393         There is an unlikely race when a CodeBlock compilation fails,
394         the module compiles a new CodeBlock for that memory mode, all while
395         the CodeBlock is notifying its callbacks that it has finished.
396         There is a chance that the Module could deref its failed CodeBlock 
397         at that point, destroying it, before the callbacks were able to
398         grab a Ref to the CodeBlock. This patch fixes the race by having the
399         callbacks ref the CodeBlock.
400
401         This patch also has the Plan clear out all of its callbacks
402         once it gets completed. This adds an extra defense to anybody
403         that grabs refs to the Plan in the callback.
404
405         * wasm/WasmCodeBlock.cpp:
406         (JSC::Wasm::CodeBlock::CodeBlock):
407         (JSC::Wasm::CodeBlock::compileAsync):
408         * wasm/WasmPlan.cpp:
409         (JSC::Wasm::Plan::complete):
410
411 2017-04-13  Filip Pizlo  <fpizlo@apple.com>
412
413         Air::RegLiveness should be constraint-based
414         https://bugs.webkit.org/show_bug.cgi?id=170817
415
416         Reviewed by Saam Barati.
417         
418         Previously, I changed the Air liveness analyses based on Air::Liveness<> to be
419         constraint-based and this was a significant speed-up. Now I'm adding the same
420         functionality to RegLiveness.
421         
422         This is a 1% speed-up on wasm B3 -O1 compile times.
423         
424         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
425         * b3/air/AirLivenessAdapter.h:
426         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
427         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
428         (JSC::B3::Air::LivenessAdapter::actionsAt):
429         * b3/air/AirRegLiveness.cpp:
430         (JSC::B3::Air::RegLiveness::RegLiveness):
431         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness):
432         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute):
433         (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted.
434         * b3/air/AirRegLiveness.h:
435         (JSC::B3::Air::RegLiveness::Actions::Actions):
436         (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase):
437         (JSC::B3::Air::RegLiveness::LocalCalcBase::live):
438         (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive):
439         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
440         (JSC::B3::Air::RegLiveness::LocalCalc::execute):
441         (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted.
442         (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted.
443
444 2017-04-13  JF Bastien  <jfbastien@apple.com>
445
446         WebAssembly: fix windows build
447         https://bugs.webkit.org/show_bug.cgi?id=170832
448
449         Reviewed by Mark Lam.
450
451         My previous patch re-declared isIOS which AssemblerCommon.h
452         already provided, and which was already included by Options.cpp.
453
454         * runtime/Options.cpp:
455
456 2017-04-13  Saam Barati  <sbarati@apple.com>
457
458         WebAssembly: We should be able to postMessage a JSWebAssemblyModule
459         https://bugs.webkit.org/show_bug.cgi?id=170573
460
461         Reviewed by Filip Pizlo.
462
463         This patch adds a callback to JSRunLoopTimer to notify
464         clients that a timer has been set. This is used inside
465         WorkerRunLoop in WebCore so that its RunLoop can perform
466         an iteration when it sees that a timer got set.
467
468         * JavaScriptCore.xcodeproj/project.pbxproj:
469         * runtime/JSRunLoopTimer.cpp:
470         (JSC::JSRunLoopTimer::scheduleTimer):
471         (JSC::JSRunLoopTimer::addTimerSetNotification):
472         (JSC::JSRunLoopTimer::removeTimerSetNotification):
473         * runtime/JSRunLoopTimer.h:
474         * wasm/WasmCodeBlock.cpp:
475         (JSC::Wasm::CodeBlock::~CodeBlock):
476         * wasm/WasmCodeBlock.h:
477         * wasm/WasmModule.cpp:
478         (JSC::Wasm::Module::~Module):
479         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
480         (JSC::Wasm::makeValidationCallback):
481         (JSC::Wasm::Module::validateSync):
482         (JSC::Wasm::Module::validateAsync):
483         (JSC::Wasm::Module::validateSyncImpl): Deleted.
484         (JSC::Wasm::Module::makeValidationCallback): Deleted.
485         * wasm/WasmModule.h:
486         (JSC::Wasm::Module::validateSync): Deleted.
487         (JSC::Wasm::Module::validateAsync): Deleted.
488         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted.
489         (JSC::Wasm::Module::nonNullCodeBlock): Deleted.
490         * wasm/js/JSWebAssemblyCodeBlock.cpp:
491         (JSC::JSWebAssemblyCodeBlock::create):
492         * wasm/js/JSWebAssemblyCodeBlock.h:
493         (JSC::JSWebAssemblyCodeBlock::create): Deleted.
494         * wasm/js/JSWebAssemblyModule.cpp:
495         (JSC::JSWebAssemblyModule::source):
496         * wasm/js/JSWebAssemblyModule.h:
497         (JSC::JSWebAssemblyModule::source): Deleted.
498         * wasm/js/WebAssemblyFunction.cpp:
499         (JSC::callWebAssemblyFunction):
500         * wasm/js/WebAssemblyModulePrototype.cpp:
501
502 2017-04-13  Mark Lam  <mark.lam@apple.com>
503
504         Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
505         https://bugs.webkit.org/show_bug.cgi?id=170661
506         <rdar://problem/31579046>
507
508         Reviewed by Filip Pizlo.
509
510         Previously, we were using flush() to flush the outermost frame's scopeRegister.
511         This is incorrect because flush() expects the VirtualRegister value passed to
512         it to be that of the top most inlined frame.  In the event that we reach a
513         terminal condition while inside an inlined frame, flush() will end up flushing
514         the wrong register.  The fix is simply to use flushDirect() instead.
515
516         * dfg/DFGByteCodeParser.cpp:
517         (JSC::DFG::ByteCodeParser::flush):
518
519 2017-04-13  Andy VanWagoner  <thetalecrafter@gmail.com>
520
521         Change Intl prototypes to plain objects
522         https://bugs.webkit.org/show_bug.cgi?id=168178
523
524         Reviewed by JF Bastien.
525
526         * builtins/StringPrototype.js:
527         (localeCompare): Create default Collator once instead of using prototype.
528         * runtime/IntlCollatorPrototype.cpp:
529         (JSC::IntlCollatorPrototype::IntlCollatorPrototype):
530         * runtime/IntlCollatorPrototype.h:
531         * runtime/IntlDateTimeFormatPrototype.cpp:
532         (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
533         * runtime/IntlDateTimeFormatPrototype.h:
534         * runtime/IntlNumberFormatPrototype.cpp:
535         (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
536         * runtime/IntlNumberFormatPrototype.h:
537         * runtime/IntlObject.cpp:
538         (JSC::IntlObject::finishCreation): Don't set constructor on each prototype.
539
540 2017-04-13  Oliver Hunt  <oliver@apple.com>
541
542         allocationSize should use safe arithmetic by default
543         https://bugs.webkit.org/show_bug.cgi?id=170804
544
545         Reviewed by JF Bastien.
546
547         Make all allocationSize() functions work in terms
548         of Checked<size_t>
549
550         * runtime/DirectArguments.h:
551         (JSC::DirectArguments::offsetOfSlot):
552         (JSC::DirectArguments::allocationSize):
553         * runtime/HashMapImpl.h:
554         (JSC::HashMapBuffer::allocationSize):
555         * runtime/JSArray.h:
556         (JSC::JSArray::allocationSize):
557         * runtime/JSArrayBufferView.h:
558         (JSC::JSArrayBufferView::allocationSize):
559         * runtime/JSAsyncFunction.h:
560         (JSC::JSAsyncFunction::allocationSize):
561         * runtime/JSFixedArray.h:
562         (JSC::JSFixedArray::allocationSize):
563         * runtime/JSFunction.h:
564         (JSC::JSFunction::allocationSize):
565         * runtime/JSGeneratorFunction.h:
566         (JSC::JSGeneratorFunction::allocationSize):
567         * runtime/JSModuleNamespaceObject.h:
568         * runtime/JSObject.h:
569         (JSC::JSFinalObject::allocationSize):
570         * runtime/JSWrapperObject.h:
571         (JSC::JSWrapperObject::allocationSize):
572         * runtime/ScopedArguments.h:
573         (JSC::ScopedArguments::allocationSize):
574         * runtime/VM.h:
575         (JSC::ScratchBuffer::allocationSize):
576         * wasm/js/JSWebAssemblyCodeBlock.h:
577         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
578         (JSC::JSWebAssemblyCodeBlock::allocationSize):
579         * wasm/js/JSWebAssemblyInstance.h:
580         (JSC::JSWebAssemblyInstance::allocationSize):
581
582 2017-04-13  JF Bastien  <jfbastien@apple.com>
583
584         WebAssembly: manage memory better
585         https://bugs.webkit.org/show_bug.cgi?id=170628
586
587         Reviewed by Keith Miller, Michael Saboff.
588
589         WebAssembly fast memories weren't managed very well. This patch
590         refactors it and puts us in a good position to further improve our
591         fast memory handling in the future.
592
593         We now cache fast memories at a process granularity, but make sure
594         that they don't consume dirty pages. We add a cap to the total
595         number of allocated fast memories to avoid ASLR degradation.
596
597         We teach the GC about memories as a kind of resource it should
598         care about because it didn't have visibility into the amount of
599         memory each represented. This allows benchmarks which allocate
600         memories back-to-back to reliably get fast memories 100% of the
601         time, even on a system under load, which wasn't the case
602         before. This reliability yields roughly 8% perf bump on x86-64
603         WasmBench.
604
605         The GC heuristic is as follows: each time we allocate a fast
606         memory we notify the GC, which then keeps track of the total
607         number of fast memories allocated since it last GC'd. We
608         separately keep track of the total number of fast memories which
609         have ever existed at any point in time (cached + allocated). This
610         is a monotonically-increasing high watermark. The GC will force a
611         full collection if, since it last ran, half or more of the high
612         watermark of fast memories was allocated.
613
614         At the same time, if we fail obtaining a fast memory from the
615         cache we do a GC to try to find one. If that fails we'll allocate
616         a new one (this can also fail, then we go to slow memory). This
617         can also be improved, but it's a good start.
618
619         This currently disables fast memories on iOS because getting fast
620         memories isn't a guaranteed thing. Rather, we get quite a few of
621         them and achieve significant speedups, but benchmarks which
622         allocate memories back-to-back end up falling behind because the
623         GC can conservatively hold onto memories, which then yields a perf
624         cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18
625         fast memories when in theory it should get all of them fast (as
626         MacOS does). The patch significantly improves the state of iOS
627         though, and in a follow-up we could re-enable fast memories.
628
629         Part of this good positioning is a facility to pre-allocate fast
630         memories very early at startup, before any fragmentation
631         occurs. This is currently disabled but worked extremely reliably
632         on iOS. Once we fix the above issues we'll want to re-visit and
633         turn on pre-allocation.
634
635         We also avoid locking for fast memory identification when
636         performing signal handling. I'm very nervous about acquiring locks
637         in a signal handler because in general signals can happen when
638         we've messed up. This isn't the case with fast memories: we're
639         raising a signal on purpose and handling it. However this doesn't
640         mean we won't mess up elsewhere! This will get more complicated
641         once we add support for multiple threads sharing memories and
642         being able to grow their memories. One example: the code calls
643         CRASH(), which executes the following code in release:
644
645             *(int *)(uintptr_t)0xbbadbeef = 0;
646
647         This is a segfault, which our fast memory signal handler tries to
648         handle. It does so by first figuring out whether 0xbbadbeef is in
649         a fast memory region, reqiring a lock. If we CRASH() while holding
650         the lock then our thread self-deadlocks, giving us no crash report
651         and a bad user experience.
652
653         Avoiding a lock therefore it's not about speed or reduced
654         contention. In fact, I'd use something else than a FIFO if these
655         were a concern. We're also doing syscalls, which dwarf any locking
656         cost.
657
658         We now only allocate 4GiB + redzone of 64k * 128 for fast memories
659         instead of 8GiB. This patch reuses the logic from
660         B3::WasmBoundsCheck to perform bounds checks when accesses could
661         exceed the redzone. We'll therefore benefit from CSE goodness when
662         it reaches WasmBoundsCheck. See bug #163469.
663
664         * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed
665         conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in
666         bug #170692 to prevent this type of bug once and for all.
667         (JSC::B3::Air::LowerToAir::lower):
668         * b3/B3Validate.cpp: update WasmBoundsCheck validation.
669         * b3/B3Value.cpp:
670         (JSC::B3::Value::effects): update WasmBoundsCheck effects.
671         * b3/B3WasmBoundsCheckValue.cpp:
672         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
673         (JSC::B3::WasmBoundsCheckValue::redzoneLimit):
674         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
675         * b3/B3WasmBoundsCheckValue.h:
676         (JSC::B3::WasmBoundsCheckValue::maximum):
677         * b3/air/AirCustom.cpp:
678         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
679         * b3/testb3.cpp:
680         (JSC::B3::testWasmBoundsCheck):
681         * heap/Heap.cpp:
682         (JSC::Heap::Heap):
683         (JSC::Heap::reportWebAssemblyFastMemoriesAllocated):
684         (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold):
685         (JSC::Heap::updateAllocationLimits):
686         (JSC::Heap::didAllocateWebAssemblyFastMemories):
687         (JSC::Heap::shouldDoFullCollection):
688         (JSC::Heap::collectIfNecessaryOrDefer):
689         * heap/Heap.h:
690         * runtime/InitializeThreading.cpp:
691         (JSC::initializeThreading):
692         * runtime/Options.cpp:
693         * runtime/Options.h:
694         * wasm/WasmB3IRGenerator.cpp:
695         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
696         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
697         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
698         (JSC::Wasm::B3IRGenerator::emitLoadOp):
699         (JSC::Wasm::B3IRGenerator::emitStoreOp):
700         (JSC::Wasm::createJSToWasmWrapper):
701         * wasm/WasmFaultSignalHandler.cpp:
702         (JSC::Wasm::trapHandler):
703         * wasm/WasmMemory.cpp: Rewrite.
704         (JSC::Wasm::makeString):
705         (JSC::Wasm::Memory::initializePreallocations):
706         (JSC::Wasm::Memory::createImpl):
707         (JSC::Wasm::Memory::create):
708         (JSC::Wasm::Memory::~Memory):
709         (JSC::Wasm::Memory::fastMappedRedzoneBytes):
710         (JSC::Wasm::Memory::fastMappedBytes):
711         (JSC::Wasm::Memory::maxFastMemoryCount):
712         (JSC::Wasm::Memory::addressIsInActiveFastMemory):
713         (JSC::Wasm::Memory::grow):
714         * wasm/WasmMemory.h:
715         (Memory::maxFastMemoryCount):
716         (Memory::addressIsInActiveFastMemory):
717         * wasm/js/JSWebAssemblyInstance.cpp:
718         (JSC::JSWebAssemblyInstance::finishCreation):
719         (JSC::JSWebAssemblyInstance::visitChildren):
720         (JSC::JSWebAssemblyInstance::globalMemoryByteSize):
721         * wasm/js/JSWebAssemblyInstance.h:
722         * wasm/js/JSWebAssemblyMemory.cpp:
723         (JSC::JSWebAssemblyMemory::grow):
724         (JSC::JSWebAssemblyMemory::finishCreation):
725         (JSC::JSWebAssemblyMemory::visitChildren):
726
727 2017-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>
728
729         [JSC] Use proper ifdef guard for code using MachineContext
730         https://bugs.webkit.org/show_bug.cgi?id=170800
731
732         Reviewed by Carlos Alberto Lopez Perez.
733
734         This patch drops MachineContext use if it is not available.
735         This situation can be considered like, building WebKit with musl.
736         In that case, we simply disable features that rely on MachineContext.
737         Examples are wasm fast memory, sampling profiler, and code profiling.
738
739         * runtime/Options.cpp:
740         (JSC::overrideDefaults):
741         * tools/CodeProfiling.cpp:
742         (JSC::CodeProfiling::begin):
743         (JSC::CodeProfiling::end):
744         Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded.
745         This patch just includes such platforms.
746
747         * wasm/WasmFaultSignalHandler.cpp:
748         (JSC::Wasm::enableFastMemory):
749
750 2017-04-12  Dan Bernstein  <mitz@apple.com>
751
752         [Mac] Future-proof .xcconfig files
753         https://bugs.webkit.org/show_bug.cgi?id=170802
754
755         Reviewed by Tim Horton.
756
757         * Configurations/Base.xcconfig:
758         * Configurations/DebugRelease.xcconfig:
759         * Configurations/FeatureDefines.xcconfig:
760         * Configurations/Version.xcconfig:
761
762 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
763
764         test262: test262/test/built-ins/NativeErrors/EvalError/proto.js
765         https://bugs.webkit.org/show_bug.cgi?id=170668
766
767         Reviewed by Keith Miller.
768
769         * runtime/JSGlobalObject.cpp:
770         (JSC::JSGlobalObject::init):
771         The [[Prototype]] of NativeError Constructor's should be the %Error%.
772         https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors
773
774 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
775
776         test262: test262/test/language/literals/regexp/u-dec-esc.js
777         https://bugs.webkit.org/show_bug.cgi?id=170687
778
779         Reviewed by Michael Saboff.
780
781         * yarr/YarrParser.h:
782         (JSC::Yarr::Parser::parseEscape):
783         * yarr/YarrPattern.cpp:
784         (JSC::Yarr::YarrPattern::errorMessage):
785         (JSC::Yarr::YarrPattern::compile):
786         * yarr/YarrPattern.h:
787         In unicoe patterns, invalid backreferences are an error.
788
789 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
790
791         Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp
792         https://bugs.webkit.org/show_bug.cgi?id=170799
793
794         Reviewed by Michael Saboff and Keith Miller.
795         
796         When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of
797         utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by
798         putting their declarations in AirAllocateStackByGraphColoring.h.
799         
800         That was pretty weird.
801         
802         This patch moves a family of stack allocation helper functions out of
803         AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The
804         linear scan stack allocator no longer has to include the other stack allocator's
805         header, which addresses my OCD.
806         
807         I moved the functions transitively reachable from the two functions that the linear
808         scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl")
809         and short descriptive comments. I think that such comments are useful in code that is
810         doing a convoluted version of some theoretical concept.
811         
812         No behavior change.
813
814         * CMakeLists.txt:
815         * JavaScriptCore.xcodeproj/project.pbxproj:
816         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
817         * b3/air/AirAllocateStackByGraphColoring.cpp:
818         (JSC::B3::Air::allocateStackByGraphColoring):
819         (JSC::B3::Air::allocateEscapedStackSlots): Deleted.
820         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted.
821         * b3/air/AirAllocateStackByGraphColoring.h:
822         * b3/air/AirStackAllocation.cpp: Added.
823         (JSC::B3::Air::attemptAssignment):
824         (JSC::B3::Air::assign):
825         (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize):
826         (JSC::B3::Air::allocateEscapedStackSlots):
827         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
828         * b3/air/AirStackAllocation.h: Added.
829
830 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
831
832         B3 -O1 should not allocateStackByGraphColoring
833         https://bugs.webkit.org/show_bug.cgi?id=170742
834
835         Reviewed by Keith Miller.
836         
837         One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to
838         this would be to make that phase cheaper. But it's weird that this phase reruns
839         liveness after register allocation already ran liveness. If only it could reuse the
840         liveness computed by register allocation then it would run a lot faster. At -O2, we do
841         not want this, since we run phases between register allocation and stack allocation,
842         and those phases are free to change the liveness of spill slots (in fact,
843         fixObviousSpills will both shorten and lengthen live ranges because of load and store
844         elimination, respectively). But at -O1, we don't really need to run any phases between
845         register and stack allocation.
846         
847         This changes Air's backend in the following ways:
848         
849         - Linear scan does stack allocation. This means that we don't need to run
850           allocateStackByGraphColoring at all. In reality, we reuse some of its innards, but
851           we don't run the expensive part of it (liveness->interference->coalescing->coloring).
852           This is a speed-up because we only run liveness once and reuse it for both register
853           and stack allocation.
854         
855         - Phases that previously ran between register and stack allocation are taken care of,
856           each in its own special way:
857           
858           -> handleCalleSaves: this is now a utility function called by both
859              allocateStackByGraphColoring and allocateRegistersAndStackByLinearScan.
860           
861           -> fixObviousSpills: we didn't run this at -O1, so nothing needs to be done.
862           
863           -> lowerAfterRegAlloc: this needed to be able to run before stack allocation because
864              it could change register usage (vis a vis callee saves) and it could introduce
865              spill slots. I changed this phase to have a secondary mode for when it runs after
866              stack allocation.
867         
868         - The part of allocateStackByGraphColoring that lowered stack addresses and took care
869           of the call arg area is now a separate phase called lowerStackArgs. We run this phase
870           regardless of optimization level. It's a cheap and general lowering.
871         
872         This also removes spillEverything, because we never use that phase, we never test it,
873         and it got in the way in this refactoring.
874         
875         This is a 21% speed-up on wasm -O1 compile times. This does not significantly change
876         -O1 throughput. We had already disabled allocateStack's most important optimization
877         (spill coalescing). This probably regresses average stack frame size, but I didn't
878         measure by how much. Stack frame size is really not that important. The algorithm in
879         allocateStackByGraphColoring is about much more than optimal frame size; it also
880         tries to avoid having to zero-extend 32-bit spills, it kills dead code, and of course
881         it coalesces.
882
883         * CMakeLists.txt:
884         * JavaScriptCore.xcodeproj/project.pbxproj:
885         * b3/B3Procedure.cpp:
886         (JSC::B3::Procedure::calleeSaveRegisterAtOffsetList):
887         (JSC::B3::Procedure::calleeSaveRegisters): Deleted.
888         * b3/B3Procedure.h:
889         * b3/B3StackmapGenerationParams.cpp:
890         (JSC::B3::StackmapGenerationParams::unavailableRegisters):
891         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.cpp.
892         (JSC::B3::Air::allocateRegistersAndStackByLinearScan):
893         (JSC::B3::Air::allocateRegistersByLinearScan): Deleted.
894         * b3/air/AirAllocateRegistersAndStackByLinearScan.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateRegistersByLinearScan.h.
895         * b3/air/AirAllocateRegistersByLinearScan.cpp: Removed.
896         * b3/air/AirAllocateRegistersByLinearScan.h: Removed.
897         * b3/air/AirAllocateStackByGraphColoring.cpp:
898         (JSC::B3::Air::allocateEscapedStackSlots):
899         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
900         (JSC::B3::Air::allocateStackByGraphColoring):
901         * b3/air/AirAllocateStackByGraphColoring.h:
902         * b3/air/AirArg.cpp:
903         (JSC::B3::Air::Arg::stackAddr):
904         * b3/air/AirArg.h:
905         (JSC::B3::Air::Arg::stackAddr): Deleted.
906         * b3/air/AirCode.cpp:
907         (JSC::B3::Air::Code::addStackSlot):
908         (JSC::B3::Air::Code::setCalleeSaveRegisterAtOffsetList):
909         (JSC::B3::Air::Code::calleeSaveRegisterAtOffsetList):
910         (JSC::B3::Air::Code::dump):
911         * b3/air/AirCode.h:
912         (JSC::B3::Air::Code::setStackIsAllocated):
913         (JSC::B3::Air::Code::stackIsAllocated):
914         (JSC::B3::Air::Code::calleeSaveRegisters):
915         * b3/air/AirGenerate.cpp:
916         (JSC::B3::Air::prepareForGeneration):
917         (JSC::B3::Air::generate):
918         * b3/air/AirHandleCalleeSaves.cpp:
919         (JSC::B3::Air::handleCalleeSaves):
920         * b3/air/AirHandleCalleeSaves.h:
921         * b3/air/AirLowerAfterRegAlloc.cpp:
922         (JSC::B3::Air::lowerAfterRegAlloc):
923         * b3/air/AirLowerStackArgs.cpp: Added.
924         (JSC::B3::Air::lowerStackArgs):
925         * b3/air/AirLowerStackArgs.h: Added.
926         * b3/testb3.cpp:
927         (JSC::B3::testPinRegisters):
928         * ftl/FTLCompile.cpp:
929         (JSC::FTL::compile):
930         * jit/RegisterAtOffsetList.h:
931         * wasm/WasmB3IRGenerator.cpp:
932         (JSC::Wasm::parseAndCompile):
933
934 2017-04-12  Michael Saboff  <msaboff@apple.com>
935
936         Implement Object.isFrozen() and Object.isSealed() per ECMA spec
937         https://bugs.webkit.org/show_bug.cgi?id=170753
938
939         Reviewed by Mark Lam.
940
941         * runtime/ObjectConstructor.cpp:
942         (JSC::testIntegrityLevel): Added local helper as described in the ECMA standard.
943
944         (JSC::objectConstructorSeal):
945         (JSC::objectConstructorFreeze):
946         Eliminated incomplete special handling of JSFinalObjects.
947
948         (JSC::objectConstructorIsSealed):
949         (JSC::objectConstructorIsFrozen):
950         Refactored to use the new testIntegrityLevel() helper.
951
952 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
953
954         Use HAVE(MACHINE_CONTEXT) instead of USE(MACHINE_CONTEXT)
955         https://bugs.webkit.org/show_bug.cgi?id=170770
956
957         Rubber stamped by Mark Lam.
958
959         * heap/MachineStackMarker.cpp:
960         (JSC::MachineThreads::MachineThread::Registers::framePointer):
961         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
962         (JSC::MachineThreads::MachineThread::Registers::llintPC):
963         * runtime/MachineContext.h:
964         (JSC::MachineContext::stackPointer):
965         (JSC::MachineContext::framePointer):
966         (JSC::MachineContext::instructionPointer):
967         (JSC::MachineContext::argumentPointer<1>):
968         (JSC::MachineContext::llintInstructionPointer):
969
970 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
971
972         [JSC] Clean up heap/MachineStackMarker by introducing USE(MACHINE_CONTEXT)
973         https://bugs.webkit.org/show_bug.cgi?id=170770
974
975         Reviewed by Mark Lam.
976
977         We use USE(MACHINE_CONTEXT) to clean up runtime/MachineContext.h. And
978         we clean up heap/MachineStackMarker.cpp by using MachineContext functions.
979
980         * heap/MachineStackMarker.cpp:
981         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
982         (JSC::MachineThreads::MachineThread::Registers::framePointer):
983         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
984         (JSC::MachineThreads::MachineThread::Registers::llintPC):
985         * heap/MachineStackMarker.h:
986         * runtime/MachineContext.h:
987         (JSC::MachineContext::stackPointer):
988         (JSC::MachineContext::framePointer):
989         (JSC::MachineContext::instructionPointer):
990         (JSC::MachineContext::argumentPointer<1>):
991         (JSC::MachineContext::llintInstructionPointer):
992
993 2017-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
994
995         [WTF] Introduce Thread class and use RefPtr<Thread> and align Windows Threading implementation semantics to Pthread one
996         https://bugs.webkit.org/show_bug.cgi?id=170502
997
998         Reviewed by Mark Lam.
999
1000         * API/tests/CompareAndSwapTest.cpp:
1001         (testCompareAndSwap):
1002         * JavaScriptCore.xcodeproj/project.pbxproj:
1003         * b3/air/testair.cpp:
1004         * b3/testb3.cpp:
1005         (JSC::B3::run):
1006         * bytecode/SuperSampler.cpp:
1007         (JSC::initializeSuperSampler):
1008         * dfg/DFGWorklist.cpp:
1009         * disassembler/Disassembler.cpp:
1010         * heap/Heap.cpp:
1011         (JSC::Heap::lastChanceToFinalize):
1012         (JSC::Heap::notifyIsSafeToCollect):
1013         * heap/Heap.h:
1014         * heap/MachineStackMarker.cpp:
1015         (JSC::MachineThreads::~MachineThreads):
1016         (JSC::MachineThreads::addCurrentThread):
1017         (JSC::MachineThreads::removeThread):
1018         (JSC::MachineThreads::removeThreadIfFound):
1019         (JSC::MachineThreads::MachineThread::MachineThread):
1020         (JSC::MachineThreads::MachineThread::getRegisters):
1021         (JSC::MachineThreads::MachineThread::Registers::stackPointer):
1022         (JSC::MachineThreads::MachineThread::Registers::framePointer):
1023         (JSC::MachineThreads::MachineThread::Registers::instructionPointer):
1024         (JSC::MachineThreads::MachineThread::Registers::llintPC):
1025         (JSC::MachineThreads::MachineThread::captureStack):
1026         (JSC::MachineThreads::tryCopyOtherThreadStack):
1027         (JSC::MachineThreads::tryCopyOtherThreadStacks):
1028         (pthreadSignalHandlerSuspendResume): Deleted.
1029         (JSC::threadData): Deleted.
1030         (JSC::MachineThreads::Thread::Thread): Deleted.
1031         (JSC::MachineThreads::Thread::createForCurrentThread): Deleted.
1032         (JSC::MachineThreads::Thread::operator==): Deleted.
1033         (JSC::MachineThreads::machineThreadForCurrentThread): Deleted.
1034         (JSC::MachineThreads::ThreadData::ThreadData): Deleted.
1035         (JSC::MachineThreads::ThreadData::~ThreadData): Deleted.
1036         (JSC::MachineThreads::ThreadData::suspend): Deleted.
1037         (JSC::MachineThreads::ThreadData::resume): Deleted.
1038         (JSC::MachineThreads::ThreadData::getRegisters): Deleted.
1039         (JSC::MachineThreads::ThreadData::Registers::stackPointer): Deleted.
1040         (JSC::MachineThreads::ThreadData::Registers::framePointer): Deleted.
1041         (JSC::MachineThreads::ThreadData::Registers::instructionPointer): Deleted.
1042         (JSC::MachineThreads::ThreadData::Registers::llintPC): Deleted.
1043         (JSC::MachineThreads::ThreadData::freeRegisters): Deleted.
1044         (JSC::MachineThreads::ThreadData::captureStack): Deleted.
1045         * heap/MachineStackMarker.h:
1046         (JSC::MachineThreads::MachineThread::suspend):
1047         (JSC::MachineThreads::MachineThread::resume):
1048         (JSC::MachineThreads::MachineThread::threadID):
1049         (JSC::MachineThreads::MachineThread::stackBase):
1050         (JSC::MachineThreads::MachineThread::stackEnd):
1051         (JSC::MachineThreads::threadsListHead):
1052         (JSC::MachineThreads::Thread::operator!=): Deleted.
1053         (JSC::MachineThreads::Thread::suspend): Deleted.
1054         (JSC::MachineThreads::Thread::resume): Deleted.
1055         (JSC::MachineThreads::Thread::getRegisters): Deleted.
1056         (JSC::MachineThreads::Thread::freeRegisters): Deleted.
1057         (JSC::MachineThreads::Thread::captureStack): Deleted.
1058         (JSC::MachineThreads::Thread::platformThread): Deleted.
1059         (JSC::MachineThreads::Thread::stackBase): Deleted.
1060         (JSC::MachineThreads::Thread::stackEnd): Deleted.
1061         * jit/ICStats.cpp:
1062         (JSC::ICStats::ICStats):
1063         (JSC::ICStats::~ICStats):
1064         * jit/ICStats.h:
1065         * jsc.cpp:
1066         (functionDollarAgentStart):
1067         (startTimeoutThreadIfNeeded):
1068         * runtime/JSLock.cpp:
1069         (JSC::JSLock::lock):
1070         * runtime/JSLock.h:
1071         (JSC::JSLock::ownerThread):
1072         (JSC::JSLock::currentThreadIsHoldingLock):
1073         * runtime/SamplingProfiler.cpp:
1074         (JSC::FrameWalker::isValidFramePointer):
1075         (JSC::SamplingProfiler::SamplingProfiler):
1076         (JSC::SamplingProfiler::createThreadIfNecessary):
1077         (JSC::SamplingProfiler::takeSample):
1078         * runtime/SamplingProfiler.h:
1079         * runtime/VM.h:
1080         (JSC::VM::ownerThread):
1081         * runtime/VMTraps.cpp:
1082         (JSC::findActiveVMAndStackBounds):
1083         (JSC::VMTraps::SignalSender::send):
1084         (JSC::VMTraps::fireTrap):
1085
1086 2017-04-11  Dean Jackson  <dino@apple.com>
1087
1088         Disable outdated WritableStream API
1089         https://bugs.webkit.org/show_bug.cgi?id=170749
1090         <rdar://problem/31446233>
1091
1092         Reviewed by Tim Horton.
1093
1094         The API we implement is no longer accurate. Disable it until we
1095         are compatible with the new specification
1096
1097         * Configurations/FeatureDefines.xcconfig:
1098
1099 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1100
1101         Unreviewed, build fix for CF ports after r215241
1102         https://bugs.webkit.org/show_bug.cgi?id=170725
1103
1104         * heap/GCActivityCallback.cpp:
1105         (JSC::GCActivityCallback::nextFireTime):
1106
1107 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1108
1109         [WebCore][JSC] ResourceUsageData.{timeOfNextEdenCollection,timeOfNextFullCollection} should be MonotonicTime
1110         https://bugs.webkit.org/show_bug.cgi?id=170725
1111
1112         Reviewed by Sam Weinig.
1113
1114         This patch makes GCActivityCallback return MonotonicTime instead of raw double value.
1115
1116         * heap/GCActivityCallback.cpp:
1117         (JSC::GCActivityCallback::nextFireTime):
1118         * heap/GCActivityCallback.h:
1119
1120 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
1121
1122         [jsc] Add missing MacroAssemblerMIPS::or32() implementation
1123         https://bugs.webkit.org/show_bug.cgi?id=169714
1124
1125         Reviewed by Michael Catanzaro.
1126
1127         * assembler/MacroAssemblerMIPS.h:
1128         (JSC::MacroAssemblerMIPS::or32):
1129         Added or32(TrustedImm32, Address).
1130
1131 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
1132
1133         test262: test262/test/annexB/language/comments/multi-line-html-close.js
1134         https://bugs.webkit.org/show_bug.cgi?id=170648
1135
1136         Reviewed by Keith Miller.
1137
1138         * parser/Lexer.cpp:
1139         (JSC::Lexer<T>::lex):
1140         A multi-line comment that contains a line terminator is itself treated
1141         like a line terminator. An HTML Close Comment that comes after it can
1142         therefore treat it like it is at the start of a line, because it was
1143         immediately preceeded by the equivalent of a line terminator.
1144
1145 2017-04-11  Joseph Pecoraro  <pecoraro@apple.com>
1146
1147         test262: test262/test/built-ins/Array/S15.4.3_A2.2.js
1148         https://bugs.webkit.org/show_bug.cgi?id=170652
1149
1150         Reviewed by Michael Saboff.
1151
1152         * runtime/ArrayConstructor.cpp:
1153         (JSC::ArrayConstructor::finishCreation):
1154         * runtime/BooleanConstructor.cpp:
1155         (JSC::BooleanConstructor::finishCreation):
1156         * runtime/DateConstructor.cpp:
1157         (JSC::DateConstructor::finishCreation):
1158         * runtime/FunctionConstructor.cpp:
1159         (JSC::FunctionConstructor::finishCreation):
1160         * runtime/JSArrayBufferConstructor.cpp:
1161         (JSC::JSArrayBufferConstructor::finishCreation):
1162         * runtime/NumberConstructor.cpp:
1163         (JSC::NumberConstructor::finishCreation):
1164         * runtime/ObjectConstructor.cpp:
1165         (JSC::ObjectConstructor::finishCreation):
1166         * runtime/RegExpConstructor.cpp:
1167         (JSC::RegExpConstructor::finishCreation):
1168         * runtime/StringConstructor.cpp:
1169         (JSC::StringConstructor::finishCreation):
1170         * runtime/SymbolConstructor.cpp:
1171         (JSC::SymbolConstructor::finishCreation):
1172         Ensure the "length" property on these native constructors is configurable (deletable).
1173
1174 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1175
1176         Unreviewed, build fix for Windows after r215228 part 2
1177         https://bugs.webkit.org/show_bug.cgi?id=170723
1178
1179         Since GCActivityCallback class is annotated exported, we do not need to annotate each member.
1180
1181         * heap/GCActivityCallback.h:
1182
1183 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1184
1185         [JSC][GTK] Use RunLoop::Timer in GTK port
1186         https://bugs.webkit.org/show_bug.cgi?id=170723
1187
1188         Reviewed by Carlos Garcia Campos.
1189
1190         This patch makes GTK port use RunLoop::Timer for JSRunLoopTimer.
1191         Only Cocoa-based ports use platform-specific Timer because it
1192         has additional feature that changes RunLoop to the WebThread one.
1193
1194         And we enable Heap timers in all the ports including JSCOnly port.
1195
1196         * heap/EdenGCActivityCallback.cpp:
1197         (JSC::EdenGCActivityCallback::lastGCLength):
1198         * heap/EdenGCActivityCallback.h:
1199         * heap/FullGCActivityCallback.cpp:
1200         (JSC::FullGCActivityCallback::lastGCLength):
1201         * heap/FullGCActivityCallback.h:
1202         * heap/GCActivityCallback.cpp:
1203         (JSC::GCActivityCallback::GCActivityCallback):
1204         (JSC::GCActivityCallback::doWork):
1205         (JSC::GCActivityCallback::scheduleTimer):
1206         (JSC::GCActivityCallback::cancelTimer):
1207         (JSC::GCActivityCallback::nextFireTime):
1208         (JSC::GCActivityCallback::didAllocate):
1209         * heap/GCActivityCallback.h:
1210         * heap/IncrementalSweeper.cpp:
1211         (JSC::IncrementalSweeper::doWork):
1212         (JSC::IncrementalSweeper::doSweep):
1213         * heap/IncrementalSweeper.h:
1214         * heap/StopIfNecessaryTimer.cpp:
1215         (JSC::StopIfNecessaryTimer::scheduleSoon):
1216         * runtime/JSRunLoopTimer.cpp:
1217         (JSC::JSRunLoopTimer::setRunLoop):
1218         (JSC::JSRunLoopTimer::scheduleTimer):
1219         (JSC::JSRunLoopTimer::cancelTimer):
1220         (JSC::JSRunLoopTimer::JSRunLoopTimer):
1221         (JSC::JSRunLoopTimer::~JSRunLoopTimer):
1222         (JSC::JSRunLoopTimer::timerDidFireCallback):
1223         * runtime/JSRunLoopTimer.h:
1224         * runtime/PromiseDeferredTimer.cpp:
1225         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
1226
1227 2017-04-11  Guillaume Emont  <guijemont@igalia.com>
1228
1229         [jsc][mips] Add missing MacroAssembler functions after r214187
1230         https://bugs.webkit.org/show_bug.cgi?id=170089
1231
1232         Reviewed by Yusuke Suzuki.
1233
1234         * assembler/MacroAssemblerMIPS.h:
1235         (JSC::MacroAssemblerMIPS::loadFloat): Added.
1236         (JSC::MacroAssemblerMIPS::storeFloat): Added.
1237
1238 2017-04-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1239
1240         [JSC] Enable JSRunLoopTimer for JSCOnly and Windows
1241         https://bugs.webkit.org/show_bug.cgi?id=170655
1242
1243         Reviewed by Carlos Garcia Campos.
1244
1245         * runtime/JSRunLoopTimer.cpp:
1246         (JSC::JSRunLoopTimer::JSRunLoopTimer):
1247         (JSC::JSRunLoopTimer::scheduleTimer):
1248         (JSC::JSRunLoopTimer::cancelTimer):
1249         * runtime/JSRunLoopTimer.h:
1250
1251 2017-04-10  Alex Christensen  <achristensen@webkit.org>
1252
1253         Revert r215217
1254         https://bugs.webkit.org/show_bug.cgi?id=170703
1255
1256         * Configurations/FeatureDefines.xcconfig:
1257
1258 2017-04-10  Alex Christensen  <achristensen@webkit.org>
1259
1260         Continue enabling WebRTC
1261         https://bugs.webkit.org/show_bug.cgi?id=170703
1262
1263         Reviewed by Youenn Fablet.
1264
1265         * Configurations/FeatureDefines.xcconfig:
1266
1267 2017-04-10  Mark Lam  <mark.lam@apple.com>
1268
1269         Move ProbeContext and ProbeFunction out of AbstractMacroAssembler.
1270         https://bugs.webkit.org/show_bug.cgi?id=170681
1271
1272         Reviewed by Michael Saboff.
1273
1274         This is a refactoring step towards enabling custom probe printers the way printInternal() works for dataLog.
1275
1276         * assembler/AbstractMacroAssembler.h:
1277         (JSC::AbstractMacroAssembler::ProbeContext::gpr): Deleted.
1278         (JSC::AbstractMacroAssembler::ProbeContext::fpr): Deleted.
1279         (JSC::AbstractMacroAssembler::ProbeContext::gprName): Deleted.
1280         (JSC::AbstractMacroAssembler::ProbeContext::fprName): Deleted.
1281         * assembler/MacroAssembler.cpp:
1282         (JSC::stdFunctionCallback):
1283         (JSC::MacroAssembler::probe):
1284         * assembler/MacroAssembler.h:
1285         (JSC::ProbeContext::gpr):
1286         (JSC::ProbeContext::fpr):
1287         (JSC::ProbeContext::gprName):
1288         (JSC::ProbeContext::fprName):
1289         * assembler/MacroAssemblerARM.cpp:
1290         (JSC::MacroAssemblerARM::probe):
1291         * assembler/MacroAssemblerARM64.cpp:
1292         (JSC::arm64ProbeTrampoline):
1293         (JSC::MacroAssemblerARM64::probe):
1294         * assembler/MacroAssemblerARMv7.cpp:
1295         (JSC::MacroAssemblerARMv7::probe):
1296         * assembler/MacroAssemblerPrinter.cpp:
1297         * assembler/MacroAssemblerPrinter.h:
1298         * assembler/MacroAssemblerX86Common.cpp:
1299         (JSC::MacroAssemblerX86Common::probe):
1300         * ftl/FTLLowerDFGToB3.cpp:
1301         (JSC::FTL::DFG::LowerDFGToB3::abstractStructure):
1302         (JSC::FTL::DFG::LowerDFGToB3::probe): Deleted.
1303         - Deleted because this became a useless place-holder after the transition to B3.
1304
1305 2017-04-10  Keith Miller  <keith_miller@apple.com>
1306
1307         WebAssembly: Fix B3IRGenerator for BrTable
1308         https://bugs.webkit.org/show_bug.cgi?id=170685
1309
1310         Reviewed by JF Bastien.
1311
1312         For some reason this didn't get included in r215141.
1313
1314         This fixes an issue with BrTable and loops where we would use the loop's return type
1315         as the branch target type.
1316
1317         * wasm/WasmB3IRGenerator.cpp:
1318         (JSC::Wasm::B3IRGenerator::ControlData::resultForBranch):
1319         (JSC::Wasm::B3IRGenerator::unifyValuesWithBlock):
1320
1321 2017-04-08  Oliver Hunt  <oliver@apple.com>
1322
1323         Remove use of strcpy from JSC
1324         https://bugs.webkit.org/show_bug.cgi?id=170646
1325
1326         Reviewed by Mark Lam.
1327
1328         Replace the use of strcpy with memcpy as strcpy keeps
1329         on tripping various analyser warnings even though its
1330         trivially safe in this case.
1331
1332         Essentially code hygiene, no change in behaviour, no
1333         perf impact.
1334
1335         * dfg/DFGDisassembler.cpp:
1336         (JSC::DFG::Disassembler::dumpDisassembly):
1337
1338 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
1339
1340         test262: test262/test/annexB/language/expressions/object/__proto__-fn-name.js
1341         https://bugs.webkit.org/show_bug.cgi?id=170650
1342
1343         Reviewed by Saam Barati.
1344
1345         * parser/Parser.cpp:
1346         (JSC::Parser<LexerType>::parseClass):
1347         (JSC::Parser<LexerType>::parseProperty):
1348         There needs to be special handling of:
1349         
1350           PropertyDefinition :  PropertyName ':' AssignmentExpression
1351          
1352         When the property name is __proto__. In this case the
1353         SetFunctionName path does not happen, so the name "__proto__"
1354         is not inferred on any anonymous function. See:
1355         https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers
1356
1357         * parser/Parser.h:
1358         * parser/SyntaxChecker.h:
1359         (JSC::SyntaxChecker::createProperty):
1360         * parser/ASTBuilder.h:
1361         (JSC::ASTBuilder::createProperty):
1362         Add an extra parameter to see if inferring / setting names are allowed.
1363
1364 2017-04-09  Joseph Pecoraro  <pecoraro@apple.com>
1365
1366         test262: test262/test/annexB/language/literals/regexp/identity-escape.js
1367         https://bugs.webkit.org/show_bug.cgi?id=170651
1368
1369         Reviewed by Saam Barati.
1370
1371         * yarr/YarrParser.h:
1372         (JSC::Yarr::Parser::parseEscape):
1373         For \8 and \9 match just the number "8" or "9" instead of both "\\" and the number.
1374         See: https://tc39.github.io/ecma262/#sec-decimalescape
1375
1376 2017-04-08  Youenn Fablet  <youenn@apple.com>
1377
1378         WebRTC tests gardening
1379         https://bugs.webkit.org/show_bug.cgi?id=170508
1380
1381         Reviewed by Eric Carlson.
1382
1383         * Configurations/FeatureDefines.xcconfig:
1384
1385 2017-04-07  Keith Miller  <keith_miller@apple.com>
1386
1387         WebAssembly: Fix issue with BrTable targeting a Loop
1388         https://bugs.webkit.org/show_bug.cgi?id=170638
1389
1390         Reviewed by Saam Barati.
1391
1392         This fixes the same issue V8 had in: https://github.com/WebAssembly/spec/pull/456#event-1033547537
1393
1394         * wasm/WasmValidate.cpp:
1395         (JSC::Wasm::Validate::ControlData::branchTargetSignature):
1396
1397 2017-04-07  Keith Miller  <keith_miller@apple.com>
1398
1399         Add a PriorityQueue class
1400         https://bugs.webkit.org/show_bug.cgi?id=170579
1401
1402         Reviewed by Saam Barati.
1403
1404         Update Wasm::Worklist to use WTF::PriorityQueue.
1405
1406         * wasm/WasmWorklist.cpp:
1407         (JSC::Wasm::Worklist::enqueue):
1408         (JSC::Wasm::Worklist::completePlanSynchronously):
1409         (JSC::Wasm::Worklist::stopAllPlansForVM):
1410         (JSC::Wasm::Worklist::~Worklist):
1411         (JSC::Wasm::Worklist::iterate): Deleted.
1412         * wasm/WasmWorklist.h:
1413         (JSC::Wasm::Worklist::isHigherPriority):
1414         (JSC::Wasm::Worklist::Comparator::operator()): Deleted.
1415
1416 2017-04-07  Yuichiro Kikura  <y.kikura@gmail.com>
1417
1418         WebGPU: implement ComputeCommandEncoder and related components
1419         https://bugs.webkit.org/show_bug.cgi?id=170444
1420
1421         Reviewed by Alex Christensen.
1422
1423         I added some identifiers related with WebGPUComputeCommandEncoder based on the proposal.
1424         https://webkit.org/wp-content/uploads/webgpu-api-proposal.html
1425
1426         * runtime/CommonIdentifiers.h:
1427
1428 2017-04-07  Saam Barati  <sbarati@apple.com>
1429
1430         WebAssembly: Module::getOrCreateCodeBlock is wrong
1431         https://bugs.webkit.org/show_bug.cgi?id=170612
1432
1433         Reviewed by Keith Miller.
1434
1435         When we were getting a module's CodeBlock, we were checking if !runnable(),
1436         and if !runnable(), we were re-creating the CodeBlock. This is wrong, since
1437         !runnable() is true while the CodeBlock is compiling. Instead, we should check
1438         if we've finished compiling, and if so, if that compilation failed.
1439
1440         * wasm/WasmModule.cpp:
1441         (JSC::Wasm::Module::getOrCreateCodeBlock):
1442
1443 2017-04-07  Saam Barati  <sbarati@apple.com>
1444
1445         WebAssembly: Make to a compilation API that allows for multi-VM concurrent compilations of Wasm Modules
1446         https://bugs.webkit.org/show_bug.cgi?id=170488
1447
1448         Reviewed by JF Bastien.
1449
1450         This patch adds a class called Wasm::Module. It contains the bits from
1451         JSWebAssemblyModule that were not VM specific. JSWebAssemblyModule
1452         now has a Ref<Wasm::Module>. Similarly, there is now a Wasm::CodeBlock,
1453         which owns the non-VM-specific bits that JSWebAssemblyCodeBlock used
1454         to own.
1455         
1456         This patch also simplifies how we verify and compile code. Wasm::Module
1457         now has an API for both sync/async validation and compilation. This
1458         API abstracts away how Wasm::Plan works.
1459         
1460         This is hopefully the last patch needed before we can implement
1461         window.postMessage for a JSWebAssemblyModule. I think all that's
1462         needed now to implement postMessage is simply creating a new
1463         JSWebAssemblyModule with the underlying Wasm::Module.
1464         
1465         This patch is neutral on WasmBench.
1466         
1467         Finally, this patch changes the promise deferred timer to
1468         allow for new tasks to be added while we're executing
1469         a task. Before, we'd deadlock if this happened.
1470
1471         * CMakeLists.txt:
1472         * JavaScriptCore.xcodeproj/project.pbxproj:
1473         * jsc.cpp:
1474         (functionTestWasmModuleFunctions):
1475         * runtime/PromiseDeferredTimer.cpp:
1476         (JSC::PromiseDeferredTimer::doWork):
1477         (JSC::PromiseDeferredTimer::scheduleWorkSoon):
1478         * runtime/PromiseDeferredTimer.h:
1479         * wasm/WasmB3IRGenerator.cpp:
1480         * wasm/WasmBinding.cpp:
1481         (JSC::Wasm::wasmToJs):
1482         (JSC::Wasm::wasmToWasm):
1483         (JSC::Wasm::exitStubGenerator): Deleted.
1484         * wasm/WasmBinding.h:
1485         * wasm/WasmCodeBlock.cpp: Added.
1486         (JSC::Wasm::CodeBlock::CodeBlock):
1487         (JSC::Wasm::CodeBlock::waitUntilFinished):
1488         (JSC::Wasm::CodeBlock::compileAsync):
1489         (JSC::Wasm::CodeBlock::isSafeToRun):
1490         * wasm/WasmCodeBlock.h: Added.
1491         (JSC::Wasm::CodeBlock::create):
1492         (JSC::Wasm::CodeBlock::compilationFinished):
1493         (JSC::Wasm::CodeBlock::runnable):
1494         (JSC::Wasm::CodeBlock::errorMessage):
1495         (JSC::Wasm::CodeBlock::functionImportCount):
1496         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
1497         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
1498         * wasm/WasmModule.cpp: Added.
1499         (JSC::Wasm::Module::Module):
1500         (JSC::Wasm::makeValidationResult):
1501         (JSC::Wasm::Module::validateSyncImpl):
1502         (JSC::Wasm::Module::getOrCreateCodeBlock):
1503         (JSC::Wasm::Module::compileSync):
1504         (JSC::Wasm::Module::makeValidationCallback):
1505         (JSC::Wasm::Module::compileAsync):
1506         * wasm/WasmModule.h: Added.
1507         (JSC::Wasm::Module::create):
1508         (JSC::Wasm::Module::validateSync):
1509         (JSC::Wasm::Module::validateAsync):
1510         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
1511         (JSC::Wasm::Module::moduleInformation):
1512         (JSC::Wasm::Module::nonNullCodeBlock):
1513         * wasm/WasmPlan.cpp:
1514         (JSC::Wasm::Plan::Plan):
1515         (JSC::Wasm::Plan::addCompletionTask):
1516         (JSC::Wasm::Plan::prepare):
1517         (JSC::Wasm::Plan::compileFunctions):
1518         (JSC::Wasm::Plan::complete):
1519         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
1520         (JSC::Wasm::Plan::cancel): Deleted.
1521         * wasm/WasmPlan.h:
1522         (JSC::Wasm::Plan::dontFinalize):
1523         (JSC::Wasm::Plan::takeWasmToWasmExitStubs):
1524         (JSC::Wasm::Plan::mode):
1525         (JSC::Wasm::Plan::takeWasmExitStubs): Deleted.
1526         (JSC::Wasm::Plan::vm): Deleted.
1527         * wasm/WasmWorklist.cpp:
1528         (JSC::Wasm::Worklist::stopAllPlansForVM):
1529         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1530         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
1531         (JSC::JSWebAssemblyCodeBlock::isSafeToRun):
1532         (JSC::JSWebAssemblyCodeBlock::initialize): Deleted.
1533         * wasm/js/JSWebAssemblyCodeBlock.h:
1534         (JSC::JSWebAssemblyCodeBlock::create):
1535         (JSC::JSWebAssemblyCodeBlock::functionImportCount):
1536         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
1537         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
1538         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
1539         (JSC::JSWebAssemblyCodeBlock::mode): Deleted.
1540         (JSC::JSWebAssemblyCodeBlock::initialized): Deleted.
1541         (JSC::JSWebAssemblyCodeBlock::plan): Deleted.
1542         (JSC::JSWebAssemblyCodeBlock::runnable): Deleted.
1543         (JSC::JSWebAssemblyCodeBlock::errorMessage): Deleted.
1544         (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee): Deleted.
1545         (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee): Deleted.
1546         * wasm/js/JSWebAssemblyInstance.cpp:
1547         (JSC::JSWebAssemblyInstance::finalizeCreation):
1548         (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock): Deleted.
1549         * wasm/js/JSWebAssemblyInstance.h:
1550         (JSC::JSWebAssemblyInstance::initialized): Deleted.
1551         * wasm/js/JSWebAssemblyModule.cpp:
1552         (JSC::JSWebAssemblyModule::createStub):
1553         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
1554         (JSC::JSWebAssemblyModule::finishCreation):
1555         * wasm/js/JSWebAssemblyModule.h:
1556         (JSC::JSWebAssemblyModule::moduleInformation):
1557         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
1558         (JSC::JSWebAssemblyModule::module):
1559         * wasm/js/WebAssemblyFunction.cpp:
1560         (JSC::WebAssemblyFunction::create):
1561         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1562         (JSC::constructJSWebAssemblyInstance):
1563         * wasm/js/WebAssemblyModuleConstructor.cpp:
1564         (JSC::WebAssemblyModuleConstructor::createModule):
1565         * wasm/js/WebAssemblyPrototype.cpp:
1566         (JSC::reject):
1567         (JSC::webAssemblyCompileFunc):
1568         (JSC::resolve):
1569         (JSC::instantiate):
1570         (JSC::compileAndInstantiate):
1571         (JSC::webAssemblyValidateFunc):
1572
1573 2017-04-07  Carlos Garcia Campos  <cgarcia@igalia.com>
1574
1575         [GTK] Update the priorities used in glib main loop sources
1576         https://bugs.webkit.org/show_bug.cgi?id=170457
1577
1578         Reviewed by Žan Doberšek.
1579
1580         * runtime/JSRunLoopTimer.cpp:
1581         (JSC::JSRunLoopTimer::JSRunLoopTimer):
1582
1583 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
1584
1585         Rename allocateStack to allocateStackByGraphColoring.
1586
1587         Rubber stamped by Saam Barati.
1588
1589         * CMakeLists.txt:
1590         * JavaScriptCore.xcodeproj/project.pbxproj:
1591         * b3/air/AirAllocateStack.cpp: Removed.
1592         * b3/air/AirAllocateStack.h: Removed.
1593         * b3/air/AirAllocateStackByGraphColoring.cpp: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.cpp.
1594         (JSC::B3::Air::allocateStackByGraphColoring):
1595         (JSC::B3::Air::allocateStack): Deleted.
1596         * b3/air/AirAllocateStackByGraphColoring.h: Copied from Source/JavaScriptCore/b3/air/AirAllocateStack.h.
1597         * b3/air/AirGenerate.cpp:
1598         (JSC::B3::Air::prepareForGeneration):
1599
1600 2017-04-06  Michael Saboff  <msaboff@apple.com>
1601
1602         Cannot Object.seal() or Object.freeze() global "this"
1603         https://bugs.webkit.org/show_bug.cgi?id=170549
1604
1605         Reviewed by Mark Lam.
1606
1607         Needed to implement JSProxy::isExtensible() which returns the results of calling
1608         the same on wrapped object.
1609
1610         Implemented step 11 of Runtime Semantics: EvalDeclarationInstantiation from the ECMAScript
1611         spec to properly return a TypeError object when attempting to add properties to a
1612         non-extensible global object.
1613
1614         * interpreter/Interpreter.cpp:
1615         (JSC::Interpreter::execute):
1616         * runtime/JSProxy.cpp:
1617         (JSC::JSProxy::isExtensible):
1618         * runtime/JSProxy.h:
1619
1620 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
1621
1622         Linear scan should run liveness only once
1623         https://bugs.webkit.org/show_bug.cgi?id=170569
1624
1625         Reviewed by Keith Miller.
1626         
1627         Air has a longstanding design bug that Tmps from different banks are indexed independently. This
1628         means that all of our analyses over Tmps do separate GP and FP passes. This does have some
1629         marginal benefits (the rest of the algorithm is specialized for Bank) but it's probably net bad.
1630         However, I don't want to think about solving that general problem.
1631         
1632         Instead, this just makes linear scan use a UnifiedTmpLiveness that uses a single "linear"
1633         indexing for GP and FP. This lets me avoid the much larger refactoring (which would involve
1634         substantial changes in graph coloring) while getting the bulk of the benefit (liveness runs once,
1635         instead of twice, for linear scan).
1636         
1637         This patch implements a lot of plumbing to make it possible for Liveness<> to view Tmps as having
1638         a unified indexing scheme. Tmp calls this LinearlyIndexed (to match the naming convention of
1639         AbsolutelyIndexed and Indexed), while AirLiveness calls this UnifiedTmpLiveness. With this
1640         change, -O1 never does any liveness analysis that uses separate GP and FP passes. I think this
1641         eliminates any urgency from the larger Tmp indexing bug. We can probably live with graph coloring
1642         doing separate passes.
1643         
1644         This is a ~6% speed-up for wasm -O1 compile times. I think this means that linear scan is no
1645         longer the longest pole in the tent.
1646
1647         * JavaScriptCore.xcodeproj/project.pbxproj:
1648         * b3/B3VariableLiveness.h:
1649         (JSC::B3::VariableLivenessAdapter::prepareToCompute):
1650         * b3/air/AirAllocateRegistersByLinearScan.cpp:
1651         (JSC::B3::Air::allocateRegistersByLinearScan):
1652         * b3/air/AirCode.h:
1653         (JSC::B3::Air::Code::forEachTmp):
1654         * b3/air/AirLiveness.h:
1655         * b3/air/AirLivenessAdapter.h:
1656         (JSC::B3::Air::LivenessAdapter::Actions::Actions):
1657         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
1658         (JSC::B3::Air::LivenessAdapter::adapter):
1659         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
1660         (JSC::B3::Air::LivenessAdapter::actionsAt):
1661         (JSC::B3::Air::LivenessAdapter::forEachUse):
1662         (JSC::B3::Air::LivenessAdapter::forEachDef):
1663         (JSC::B3::Air::TmpLivenessAdapter::numIndices):
1664         (JSC::B3::Air::UnifiedTmpLivenessAdapter::UnifiedTmpLivenessAdapter):
1665         (JSC::B3::Air::UnifiedTmpLivenessAdapter::numIndices):
1666         (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsBank):
1667         (JSC::B3::Air::UnifiedTmpLivenessAdapter::acceptsRole):
1668         (JSC::B3::Air::UnifiedTmpLivenessAdapter::valueToIndex):
1669         (JSC::B3::Air::UnifiedTmpLivenessAdapter::indexToValue):
1670         * b3/air/AirLivenessConstraints.h: Removed.
1671         * b3/air/AirRegLiveness.h:
1672         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
1673         * b3/air/AirTmp.cpp:
1674         * b3/air/AirTmp.h:
1675         * b3/air/AirTmpInlines.h:
1676         (JSC::B3::Air::Tmp::LinearlyIndexed::LinearlyIndexed):
1677         (JSC::B3::Air::Tmp::LinearlyIndexed::index):
1678         (JSC::B3::Air::Tmp::linearlyIndexed):
1679         (JSC::B3::Air::Tmp::indexEnd):
1680         (JSC::B3::Air::Tmp::absoluteIndexEnd):
1681         (JSC::B3::Air::Tmp::linearIndexEnd):
1682         (JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
1683         (JSC::B3::Air::Tmp::tmpForLinearIndex):
1684         * b3/air/AirTmpMap.h: Added.
1685         (JSC::B3::Air::TmpMap::TmpMap):
1686         (JSC::B3::Air::TmpMap::resize):
1687         (JSC::B3::Air::TmpMap::clear):
1688         (JSC::B3::Air::TmpMap::operator[]):
1689         (JSC::B3::Air::TmpMap::append):
1690
1691 2017-04-06  Ryan Haddad  <ryanhaddad@apple.com>
1692
1693         Unreviewed, rolling out r215046.
1694
1695         This change broke internal builds.
1696
1697         Reverted changeset:
1698
1699         "WebRTC tests gardening"
1700         https://bugs.webkit.org/show_bug.cgi?id=170508
1701         http://trac.webkit.org/changeset/215046
1702
1703 2017-04-06  Joseph Pecoraro  <pecoraro@apple.com>
1704
1705         Web Inspector: Show all headers in the Request Headers section of the Resource details sidebar
1706         https://bugs.webkit.org/show_bug.cgi?id=16531
1707         <rdar://problem/5712895>
1708
1709         Reviewed by Timothy Hatcher.
1710
1711         * inspector/protocol/Network.json:
1712         Optional refined list of request headers in Metrics.
1713
1714 2017-04-06  Filip Pizlo  <fpizlo@apple.com>
1715
1716         B3 -O1 should generate better code than -O0
1717         https://bugs.webkit.org/show_bug.cgi?id=170563
1718
1719         Reviewed by Michael Saboff.
1720         
1721         Prior to this change, code generated by -O1 ran slower than code generated by -O0. This turned
1722         out to be because of reduceStrength optimizations that increase live ranges and create register
1723         pressure, which then creates problems for linear scan.
1724         
1725         It seemed obvious that canonicalizations that help isel, constant folding, and one-for-one
1726         strength reductions should stay. It also seemed obvious that SSA and CFG simplification are fast
1727         and harmless. So, I focused on removing:
1728         
1729         - CSE, which increases live ranges. This is a risky optimization when we know that we've chosen
1730           to use a bad register allocator.
1731         
1732         - Sophisticated strength reductions that create more code, like the insane division optimization.
1733         
1734         - Anything that inserts basic blocks.
1735         
1736         CSE appeared to be the cause of half of the throughput regression of -O1 but none of the compile
1737         time. This change also reduces the running time of reduceStrength by making it not a fixpoint at
1738         optLevel<2.
1739         
1740         This makes wasm -O1 compile 17% faster. This makes wasm -O1 run 19% faster. This makes -O1 code
1741         run 3% faster than -O0, and compile about 4% slower than -O0. We may yet end up choosing to use
1742         -O0, but at least now -O1 isn't totally useless.
1743
1744         * b3/B3ReduceStrength.cpp:
1745
1746 2017-04-06  Jon Davis  <jond@apple.com>
1747
1748         Updates feature status for recently shipped features
1749         https://bugs.webkit.org/show_bug.cgi?id=170359
1750
1751         Reviewed by Brian Burg.
1752
1753         Changed "Done" status to "Supported".
1754
1755         * features.json:
1756
1757 2017-04-06  Youenn Fablet  <youenn@apple.com>
1758
1759         WebRTC tests gardening
1760         https://bugs.webkit.org/show_bug.cgi?id=170508
1761
1762         Reviewed by Eric Carlson.
1763
1764         * Configurations/FeatureDefines.xcconfig:
1765
1766 2017-04-06  Guillaume Emont  <guijemont@igalia.com>
1767
1768         [JSC][MIPS][DFG] Use x86 generic HasOwnProperty
1769         https://bugs.webkit.org/show_bug.cgi?id=170222
1770
1771         Reviewed by Yusuke Suzuki.
1772
1773         * dfg/DFGFixupPhase.cpp:
1774         (JSC::DFG::FixupPhase::fixupNode):
1775         use the X86 special version for HasOwnProperty on MIPS too.
1776         * dfg/DFGSpeculativeJIT32_64.cpp:
1777         (JSC::DFG::SpeculativeJIT::compile):
1778         use the X86 special version for HasOwnProperty on MIPS too.
1779
1780 2017-04-05  Saam Barati  <sbarati@apple.com>
1781
1782         REGRESSION fix bad isWasm() test by ensuring proper Wasm callee bit pattern
1783         https://bugs.webkit.org/show_bug.cgi?id=170494
1784         <rdar://problem/31446485>
1785
1786         Reviewed by Yusuke Suzuki and Mark Lam.
1787
1788         This patch fixes how we test a 64 bit JSValue pattern to see if it's
1789         a Wasm callee. We now tag Wasm::Callee's with 0b011 in their lower 3 bits.
1790         The new test is for a Wasm Callee is as follows:
1791         isWasm(uint64_t x)
1792         {
1793             return x & 0xffff000000000007 == 3;
1794         }
1795         
1796         This test works because the lower 3 bits of the non-number immediate values are as follows:
1797         undefined: 0b010
1798         null:      0b010
1799         true:      0b111
1800         false:     0b110
1801         The test rejects all of these because none have just the value 3 in their lower 3 bits.
1802         The test also rejects all numbers, because they have non-zero upper 16 bits.
1803         The test also rejects normal cells because they won't have the number 3 as
1804         their lower 3 bits. Note, this bit pattern also allows the normal JSValue isCell(), etc,
1805         predicates to work on a Wasm::Callee because the various tests will fail if you
1806         bit casted a boxed Wasm::Callee* to a JSValue. isCell() would fail since it sees
1807         TagBitTypeOther. The other tests also trivially fail, since it won't be a number,
1808         and it won't be equal to null, undefined, true, or false. The isBoolean() predicate
1809         will fail because we won't have TagBitBool set.
1810
1811         * interpreter/CallFrame.h:
1812         (JSC::ExecState::guaranteedJSValueCallee):
1813         (JSC::ExecState::calleeAsValue): Deleted.
1814         * interpreter/CalleeBits.h:
1815         (JSC::CalleeBits::boxWasm):
1816         (JSC::CalleeBits::isWasm):
1817         (JSC::CalleeBits::asWasmCallee):
1818         * jit/JITOperations.cpp:
1819         * runtime/JSCJSValue.h:
1820
1821 2017-04-05  Keith Miller  <keith_miller@apple.com>
1822
1823         WebAssembly: Plans should be able to have more than one completion task.
1824         https://bugs.webkit.org/show_bug.cgi?id=170516
1825
1826         Reviewed by Saam Barati.
1827
1828         This patch also eliminates the need for blocked tasks on the
1829         PromiseDeferredTimer and pendingPromise on Wasm::Plan.
1830
1831         * runtime/PromiseDeferredTimer.cpp:
1832         (JSC::PromiseDeferredTimer::doWork):
1833         (JSC::PromiseDeferredTimer::cancelPendingPromise):
1834         (JSC::PromiseDeferredTimer::scheduleBlockedTask): Deleted.
1835         * runtime/PromiseDeferredTimer.h:
1836         * wasm/WasmPlan.cpp:
1837         (JSC::Wasm::Plan::Plan):
1838         (JSC::Wasm::Plan::addCompletionTask):
1839         (JSC::Wasm::Plan::complete):
1840         * wasm/WasmPlan.h:
1841         (JSC::Wasm::Plan::setMode):
1842         (JSC::Wasm::Plan::mode):
1843         (JSC::Wasm::Plan::setModeAndPromise): Deleted.
1844         (JSC::Wasm::Plan::pendingPromise): Deleted.
1845         * wasm/WasmWorklist.cpp:
1846         (JSC::Wasm::Worklist::enqueue):
1847         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1848         (JSC::constructJSWebAssemblyInstance):
1849         * wasm/js/WebAssemblyPrototype.cpp:
1850         (JSC::instantiate):
1851
1852 2017-04-05  Guilherme Iscaro  <iscaro@profusion.mobi>
1853
1854         Do not use BLX for immediates (ARM-32)
1855
1856         https://bugs.webkit.org/show_bug.cgi?id=170351
1857
1858         Reviewed by Mark Lam.
1859
1860         Currently the offline asm generator for 32-bit ARM code translates the
1861         'call' meta-instruction (which may be found in LowLevelInterpreter.asm
1862         and friends) to the ARM's BLX instrunction. The BLX instruction may be
1863         used for labels (immediates) and registers and one side effect of BLX
1864         is that it may switch the processor's instruction set.
1865         A 'BLX register' instruction will change/remain the processor state to
1866         ARM if the  register_bit[0] is set to 0 or change/remain to Thumb if
1867         register_bit[0] is set to 1. However, a 'BLX label' instruction will
1868         always switch the processor state. It switches ARM to thumb and vice-versa.
1869         This behaviour is unwanted, since the C++ code and the offlineasm generated code
1870         are both compiled using the same instruction set, thus a instruction
1871         set change will likely produce a crash. In order to fix the problem the
1872         BL instruction can be used for labels. It will branch just like BLX,
1873         but it won't change the instruction set. It's important to note that
1874         Darwin is not affected by this problem, thus to minimize the impact of
1875         this change the BL instruction will only be used on non-darwin targets.
1876
1877         BLX reference: http://infocenter.arm.com/help/topic/com.arm.doc.dui0489i/CIHBJCDC.html?resultof=%22%62%6c%78%22%20
1878
1879         * offlineasm/arm.rb:
1880
1881 2017-04-05  Keith Miller  <keith_miller@apple.com>
1882
1883         WebAssembly: We shouldn't need to pin size registers if we have a fast memory.
1884         https://bugs.webkit.org/show_bug.cgi?id=170504
1885
1886         Reviewed by Mark Lam.
1887
1888         * wasm/WasmB3IRGenerator.cpp:
1889         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1890         (JSC::Wasm::createJSToWasmWrapper):
1891         (JSC::Wasm::parseAndCompile):
1892         * wasm/WasmMemoryInformation.h:
1893         (JSC::Wasm::PinnedRegisterInfo::toSave):
1894
1895 2017-04-05  Yusuke Suzuki  <utatane.tea@gmail.com>
1896
1897         [JSC] Suppress warnings in GCC
1898         https://bugs.webkit.org/show_bug.cgi?id=170501
1899
1900         Reviewed by Keith Miller.
1901
1902         Should use ASSERT_NOT_REACHED since return-type pragma is only
1903         enabled under ASSERT_DISABLED environment. We shoud use
1904         ASSERT_NOTREACHED to emit assertions in debug build. It effectively
1905         catches bugs while keeping performance in release build.
1906
1907         * b3/B3Opcode.cpp:
1908         (JSC::B3::storeOpcode):
1909         * b3/B3Width.h:
1910         (JSC::B3::mask):
1911         * runtime/Options.cpp:
1912         (JSC::parse):
1913         * wasm/WasmSections.h:
1914         (JSC::Wasm::makeString):
1915         * wasm/WasmSignature.cpp:
1916         (JSC::Wasm::SignatureInformation::tryCleanup):
1917         * wasm/generateWasmValidateInlinesHeader.py:
1918
1919 2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>
1920
1921         Implement PromiseDeferredTimer for non CF based ports
1922         https://bugs.webkit.org/show_bug.cgi?id=170391
1923
1924         Reviewed by Yusuke Suzuki.
1925
1926         RunLoop handling is only implemented for CF causing several wasm tests to fail for other ports.
1927
1928         * jsc.cpp:
1929         (runJSC): Remove CF ifdefs.
1930         * runtime/PromiseDeferredTimer.cpp:
1931         (JSC::PromiseDeferredTimer::doWork): Add non CF implementation using WTF RunLoop.
1932         (JSC::PromiseDeferredTimer::runRunLoop): Ditto.
1933         * runtime/PromiseDeferredTimer.h:
1934
1935 2017-04-05  Carlos Garcia Campos  <cgarcia@igalia.com>
1936
1937         WebAssembly: several tests added in r214504 crash when building with GCC
1938         https://bugs.webkit.org/show_bug.cgi?id=170390
1939
1940         Reviewed by Saam Barati.
1941
1942         The pattern foo->bar([f = WTFMove(foo)]{}); crashes when building with GCC, I assume the move happens before the
1943         foo is used to invoke the function.
1944
1945         * wasm/js/WebAssemblyPrototype.cpp:
1946         (JSC::webAssemblyCompileFunc): Use p.vm() instead of plan->vm(), because plan is moved by the lambda.
1947         (JSC::instantiate): Ditto.
1948         (JSC::compileAndInstantiate): Ditto.
1949
1950 2017-03-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1951
1952         [JSC] Generate TemplateObjects at linking time
1953         https://bugs.webkit.org/show_bug.cgi?id=169743
1954
1955         Reviewed by Keith Miller.
1956
1957         Currently, the code calls getTemplateObject to get appropriate template objects at runtime.
1958         But this template object is constant value and never changed. So instead of creating it
1959         at runtime, we should create it at linking time and store it in the constant registers.
1960
1961         * builtins/BuiltinNames.h:
1962         * bytecode/CodeBlock.cpp:
1963         (JSC::CodeBlock::finishCreation):
1964         (JSC::CodeBlock::setConstantRegisters):
1965         * bytecode/CodeBlock.h:
1966         * bytecode/UnlinkedCodeBlock.cpp:
1967         (JSC::UnlinkedCodeBlock::shrinkToFit):
1968         * bytecode/UnlinkedCodeBlock.h:
1969         * bytecompiler/BytecodeGenerator.cpp:
1970         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
1971         (JSC::BytecodeGenerator::emitGetTemplateObject):
1972         * bytecompiler/BytecodeGenerator.h:
1973         * bytecompiler/NodesCodegen.cpp:
1974         (JSC::TaggedTemplateNode::emitBytecode):
1975         * runtime/JSGlobalObject.cpp:
1976         (JSC::JSGlobalObject::init):
1977         (JSC::getTemplateObject): Deleted.
1978         * runtime/JSTemplateRegistryKey.cpp:
1979         * runtime/JSTemplateRegistryKey.h:
1980         (JSC::isTemplateRegistryKey):
1981
1982 2017-04-04  Mark Lam  <mark.lam@apple.com>
1983
1984         On ARM64, DFG::SpeculativeJIT::compileArithMod() failed to ensure result is of DataFormatInt32.
1985         https://bugs.webkit.org/show_bug.cgi?id=170473
1986         <rdar://problem/29912391>
1987
1988         Reviewed by Saam Barati.
1989
1990         In Unchecked mode, when DFG::SpeculativeJIT::compileArithMod() detects that the
1991         divisor is 0, we want it to return 0.  The result is expected to be of
1992         DataFormatIn32.
1993
1994         The ARM implementation just returns the value in the divisor register.  However,
1995         the divisor in this case can be of DataFormatJSInt32.  On ARM64, returning the
1996         divisor register yields the wrong result format because the same register also
1997         holds the upper 32-bit of the JSValue encoding.  The fix is to return an
1998         immediate 0 instead.
1999
2000         Also turned on the assertion in jitAssertIsInt32 for ARM64.  This assertion being
2001         disabled may have contributed to this bug going unnoticed all this time.
2002
2003         * dfg/DFGSpeculativeJIT.cpp:
2004         (JSC::DFG::SpeculativeJIT::compileArithMod):
2005         * jit/AssemblyHelpers.cpp:
2006         (JSC::AssemblyHelpers::jitAssertIsInt32):
2007
2008 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2009
2010         Air::eliminateDeadCode should not repeatedly process the same live instructions
2011         https://bugs.webkit.org/show_bug.cgi?id=170490
2012
2013         Reviewed by Keith Miller.
2014         
2015         This makes the eliminateDeadCode() fixpoint somewhat worklist-based: we track the set
2016         of Insts that might be dead. Every time we detect that one is live, we remove it from
2017         the set. This is a big (>2x) speed-up because lots of Insts are immediately found to
2018         be live.
2019         
2020         This is a ~1% wasm -O1 compile time progression.
2021
2022         * b3/air/AirEliminateDeadCode.cpp:
2023         (JSC::B3::Air::eliminateDeadCode):
2024
2025 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2026
2027         Air::eliminateDeadCode() should not use a HashSet
2028         https://bugs.webkit.org/show_bug.cgi?id=170487
2029
2030         Reviewed by Saam Barati.
2031         
2032         Introduce TmpSet, which is like a HashSet<Tmp>. Use this to make eliminateDeadCode()
2033         about 50% faster, resulting in a 1% wasm -O1 compile time progression.
2034
2035         * JavaScriptCore.xcodeproj/project.pbxproj:
2036         * b3/air/AirEliminateDeadCode.cpp:
2037         (JSC::B3::Air::eliminateDeadCode):
2038         * b3/air/AirTmpSet.h: Added.
2039         (JSC::B3::Air::TmpSet::TmpSet):
2040         (JSC::B3::Air::TmpSet::add):
2041         (JSC::B3::Air::TmpSet::remove):
2042         (JSC::B3::Air::TmpSet::contains):
2043         (JSC::B3::Air::TmpSet::size):
2044         (JSC::B3::Air::TmpSet::isEmpty):
2045         (JSC::B3::Air::TmpSet::iterator::iterator):
2046         (JSC::B3::Air::TmpSet::iterator::operator*):
2047         (JSC::B3::Air::TmpSet::iterator::operator++):
2048         (JSC::B3::Air::TmpSet::iterator::operator==):
2049         (JSC::B3::Air::TmpSet::iterator::operator!=):
2050         (JSC::B3::Air::TmpSet::begin):
2051         (JSC::B3::Air::TmpSet::end):
2052
2053 2017-04-04  Keith Miller  <keith_miller@apple.com>
2054
2055         WebAssembly: ModuleInformation should be a ref counted thing that can be shared across threads.
2056         https://bugs.webkit.org/show_bug.cgi?id=170478
2057
2058         Reviewed by Saam Barati.
2059
2060         ModuleInformation has been moved to its own file and is now
2061         ThreadSafeRefCounted.  All the Strings we used to keep in the
2062         ModuleInformation have been switched to Vector<LChar> this has the
2063         advantage that it can be passed across threads. However, this does
2064         mean that we need to decode the utf8 strings in each thread. This
2065         is likely not a problem because:
2066
2067         1) most modules have few imports/exports/custom sections.
2068         2) most of the time they are ascii so the conversion is cheap.
2069         3) we only have to do it once per thread, and there shouldn't be too many.
2070
2071         This patch also removes
2072         moduleSignatureIndicesToUniquedSignatureIndices since that
2073         information can already be recovered from the
2074         SignatureInformation.
2075
2076         * JavaScriptCore.xcodeproj/project.pbxproj:
2077         * jsc.cpp:
2078         (functionTestWasmModuleFunctions):
2079         * runtime/Identifier.h:
2080         (JSC::Identifier::fromString):
2081         * wasm/WasmB3IRGenerator.cpp:
2082         (JSC::Wasm::parseAndCompile):
2083         * wasm/WasmB3IRGenerator.h:
2084         * wasm/WasmFormat.cpp:
2085         (JSC::Wasm::makeString):
2086         (JSC::Wasm::ModuleInformation::~ModuleInformation): Deleted.
2087         * wasm/WasmFormat.h:
2088         (JSC::Wasm::makeString):
2089         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize): Deleted.
2090         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace): Deleted.
2091         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace): Deleted.
2092         (JSC::Wasm::ModuleInformation::importFunctionCount): Deleted.
2093         (JSC::Wasm::ModuleInformation::internalFunctionCount): Deleted.
2094         * wasm/WasmFunctionParser.h:
2095         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
2096         * wasm/WasmModuleInformation.cpp: Copied from Source/JavaScriptCore/wasm/WasmValidate.h.
2097         (JSC::Wasm::ModuleInformation::~ModuleInformation):
2098         * wasm/WasmModuleInformation.h: Added.
2099         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
2100         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
2101         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
2102         (JSC::Wasm::ModuleInformation::importFunctionCount):
2103         (JSC::Wasm::ModuleInformation::internalFunctionCount):
2104         (JSC::Wasm::ModuleInformation::ModuleInformation):
2105         * wasm/WasmModuleParser.cpp:
2106         * wasm/WasmModuleParser.h:
2107         (JSC::Wasm::ModuleParser::ModuleParser):
2108         * wasm/WasmParser.h:
2109         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
2110         * wasm/WasmPlan.cpp:
2111         (JSC::Wasm::Plan::Plan):
2112         (JSC::Wasm::Plan::parseAndValidateModule):
2113         (JSC::Wasm::Plan::prepare):
2114         (JSC::Wasm::Plan::compileFunctions):
2115         (JSC::Wasm::Plan::complete):
2116         (JSC::Wasm::Plan::cancel):
2117         * wasm/WasmPlan.h:
2118         (JSC::Wasm::Plan::internalFunctionCount):
2119         (JSC::Wasm::Plan::takeModuleInformation):
2120         * wasm/WasmSignature.cpp:
2121         (JSC::Wasm::SignatureInformation::get):
2122         * wasm/WasmSignature.h:
2123         * wasm/WasmValidate.cpp:
2124         (JSC::Wasm::validateFunction):
2125         * wasm/WasmValidate.h:
2126         * wasm/js/JSWebAssemblyHelpers.h:
2127         (JSC::createSourceBufferFromValue):
2128         * wasm/js/JSWebAssemblyModule.cpp:
2129         (JSC::JSWebAssemblyModule::createStub):
2130         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
2131         (JSC::JSWebAssemblyModule::finishCreation):
2132         * wasm/js/JSWebAssemblyModule.h:
2133         (JSC::JSWebAssemblyModule::moduleInformation):
2134         (JSC::JSWebAssemblyModule::source):
2135         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2136         (JSC::constructJSWebAssemblyInstance):
2137         * wasm/js/WebAssemblyModuleConstructor.cpp:
2138         (JSC::WebAssemblyModuleConstructor::createModule):
2139         * wasm/js/WebAssemblyModulePrototype.cpp:
2140         (JSC::webAssemblyModuleProtoCustomSections):
2141         (JSC::webAssemblyModuleProtoImports):
2142         (JSC::webAssemblyModuleProtoExports):
2143         * wasm/js/WebAssemblyModuleRecord.cpp:
2144         (JSC::WebAssemblyModuleRecord::link):
2145         * wasm/js/WebAssemblyModuleRecord.h:
2146         * wasm/js/WebAssemblyPrototype.cpp:
2147         (JSC::webAssemblyCompileFunc):
2148         (JSC::instantiate):
2149         (JSC::compileAndInstantiate):
2150
2151 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2152
2153         B3::fixSSA() needs a tune-up
2154         https://bugs.webkit.org/show_bug.cgi?id=170485
2155
2156         Reviewed by Saam Barati.
2157         
2158         After the various optimizations to liveness, register allocation, and other phases, the
2159         fixSSA() phase now looks like one of the top offenders. This includes a bunch of
2160         changes to make this phase run faster. This is a ~7% wasm -O1 compile time progression.
2161         
2162         Here's what I did:
2163         
2164         - We now use IndexSparseSet instead of IndexMap for tracking variable values. This
2165           makes it cheaper to chew through small blocks while there is a non-trivial number of
2166           total variables.
2167         
2168         - We now do a "local SSA conversion" pass before anything else. This eliminates
2169           obvious Get's. If we were using temporary Variables, it would eliminate many of
2170           those. That's useful for when we use demoteValues() and duplciateTails(). For wasm
2171           -O1, we mainly care about the fact that it makes a bunch of Set's dead.
2172         
2173         - We now do a Set DCE pass after the local SSA but before SSA conversion. This ensures
2174           that any block-local live intervals of Variables disappear and don't need further
2175           consideration.
2176         
2177         - We now cache the reaching defs calculation.
2178         
2179         - We now perform the reaching defs calculation lazily.
2180
2181         * b3/B3FixSSA.cpp:
2182         (JSC::B3::demoteValues):
2183         (JSC::B3::fixSSA):
2184         * b3/B3SSACalculator.cpp:
2185         (JSC::B3::SSACalculator::reachingDefAtTail):
2186         * b3/B3VariableLiveness.cpp:
2187         (JSC::B3::VariableLiveness::VariableLiveness):
2188         * b3/air/AirLiveness.h:
2189         (JSC::B3::Air::Liveness::Liveness):
2190         * dfg/DFGLivenessAnalysisPhase.cpp:
2191         (JSC::DFG::LivenessAnalysisPhase::LivenessAnalysisPhase): Deleted.
2192         (JSC::DFG::LivenessAnalysisPhase::run): Deleted.
2193         (JSC::DFG::LivenessAnalysisPhase::processBlock): Deleted.
2194
2195 2017-04-04  Joseph Pecoraro  <pecoraro@apple.com>
2196
2197         Remove stale LLVM Header Path includes from JavaScriptCore
2198         https://bugs.webkit.org/show_bug.cgi?id=170483
2199
2200         Reviewed by Mark Lam.
2201
2202         * Configurations/Base.xcconfig:
2203
2204 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2205
2206         B3::LowerToAir incorrectly selects BitXor(AtomicStrongCAS(...), $1)
2207         https://bugs.webkit.org/show_bug.cgi?id=169867
2208
2209         Reviewed by Saam Barati.
2210         
2211         The BitXor(AtomicWeakCAS(...), $1) optimization makes a lot of sense because we an fold the
2212         BitXor into the CAS condition read-out. But there is no version of this that is profitable or
2213         correct for AtomicStrongCAS. The inversion case is handled by Equal(AtomicStrongCAS(...), ...)
2214         becoming NotEqual(AtomicStrongCAS(...), ...), and we alraedy handle that separately.
2215         
2216         So, the fix here is to make the BitXor CAS pattern only recognize AtomicWeakCAS.
2217
2218         * b3/B3LowerToAir.cpp:
2219         (JSC::B3::Air::LowerToAir::lower):
2220         * b3/testb3.cpp:
2221         (JSC::B3::testAtomicStrongCAS):
2222
2223 2017-04-04  Saam Barati  <sbarati@apple.com>
2224
2225         WebAssembly: JSWebAssemblyCallee should not be a JSCell
2226         https://bugs.webkit.org/show_bug.cgi?id=170135
2227
2228         Reviewed by Michael Saboff.
2229
2230         This patch is perhaps the last big change to the design of fundamental
2231         Wasm API to allow for PIC. It changes JSWebAssemblyCallee into a thing
2232         called Wasm::Callee. It serves the same purpose as before, except
2233         Wasm::Callee is not a JSCell. I had to refactor the various parts of the
2234         runtime that will see CallFrame's with Wasm::Callee's in the callee slot.
2235         Thankfully, the parts of the runtime that Wasm touches are limited. The
2236         main refactoring is changing the exception handling code, such as taking
2237         a stack trace, to be friendly to seeing a non JSCell callee.
2238         
2239         The callee() function on ExecState now returns a class I added in this
2240         patch called CalleeBits. CalleeBits will tell you if the callee is a
2241         JSCell or a Wasm::Callee. We tag Wasm::Callee's with a 1 in their lower
2242         bit so we can easily tell what is and isn't a Wasm::Callee.
2243         
2244         The stub that calls out from Wasm to JS still puts a JSCell callee
2245         into the call frame, even though the callee logically represents a
2246         Wasm frame. The reason for this is that we use the call IC infrastructure
2247         to make a call out to JS code, and the code that writes the IC expects
2248         a JSCell as the callee. This is knowingly part of our design. When we
2249         do structured cloning of Wasm Modules, we'll need to regenerate these
2250         JS call stubs.
2251
2252         * API/JSContextRef.cpp:
2253         (BacktraceFunctor::operator()):
2254         * CMakeLists.txt:
2255         * JavaScriptCore.xcodeproj/project.pbxproj:
2256         * debugger/Debugger.cpp:
2257         (JSC::Debugger::pauseIfNeeded):
2258         (JSC::Debugger::currentDebuggerCallFrame):
2259         * debugger/DebuggerCallFrame.cpp:
2260         (JSC::DebuggerCallFrame::create):
2261         (JSC::DebuggerCallFrame::DebuggerCallFrame):
2262         (JSC::DebuggerCallFrame::currentPosition):
2263         (JSC::DebuggerCallFrame::positionForCallFrame):
2264         * debugger/DebuggerCallFrame.h:
2265         * interpreter/CallFrame.cpp:
2266         (JSC::CallFrame::vmEntryGlobalObject):
2267         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
2268         (JSC::CallFrame::isAnyWasmCallee):
2269         (JSC::CallFrame::callerSourceOrigin):
2270         * interpreter/CallFrame.h:
2271         (JSC::ExecState::calleeAsValue):
2272         (JSC::ExecState::jsCallee):
2273         (JSC::ExecState::callee):
2274         (JSC::ExecState::unsafeCallee):
2275         (JSC::ExecState::scope):
2276         (JSC::ExecState::iterate):
2277         * interpreter/CalleeBits.h: Added.
2278         (JSC::CalleeBits::CalleeBits):
2279         (JSC::CalleeBits::operator=):
2280         (JSC::CalleeBits::boxWasm):
2281         (JSC::CalleeBits::isWasm):
2282         (JSC::CalleeBits::isCell):
2283         (JSC::CalleeBits::asCell):
2284         (JSC::CalleeBits::asWasmCallee):
2285         (JSC::CalleeBits::rawPtr):
2286         * interpreter/Interpreter.cpp:
2287         (JSC::GetStackTraceFunctor::operator()):
2288         (JSC::Interpreter::getStackTrace):
2289         (JSC::notifyDebuggerOfUnwinding):
2290         (JSC::UnwindFunctor::UnwindFunctor):
2291         (JSC::UnwindFunctor::operator()):
2292         (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
2293         (JSC::Interpreter::unwind):
2294         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
2295         * interpreter/Interpreter.h:
2296         * interpreter/Register.h:
2297         (JSC::Register::pointer):
2298         * interpreter/ShadowChicken.cpp:
2299         (JSC::ShadowChicken::update):
2300         * interpreter/ShadowChickenInlines.h:
2301         (JSC::ShadowChicken::iterate):
2302         * interpreter/StackVisitor.cpp:
2303         (JSC::StackVisitor::StackVisitor):
2304         (JSC::StackVisitor::readFrame):
2305         (JSC::StackVisitor::readNonInlinedFrame):
2306         (JSC::StackVisitor::readInlinedFrame):
2307         (JSC::StackVisitor::Frame::calleeSaveRegisters):
2308         (JSC::StackVisitor::Frame::functionName):
2309         (JSC::StackVisitor::Frame::dump):
2310         * interpreter/StackVisitor.h:
2311         (JSC::StackVisitor::Frame::callee):
2312         (JSC::StackVisitor::visit):
2313         * jit/Repatch.cpp:
2314         (JSC::linkFor):
2315         (JSC::linkPolymorphicCall):
2316         * jsc.cpp:
2317         (callWasmFunction):
2318         (functionTestWasmModuleFunctions):
2319         * runtime/ArrayPrototype.cpp:
2320         * runtime/Error.cpp:
2321         (JSC::addErrorInfoAndGetBytecodeOffset):
2322         * runtime/ErrorInstance.cpp:
2323         (JSC::ErrorInstance::finishCreation):
2324         * runtime/JSCell.cpp:
2325         (JSC::JSCell::isAnyWasmCallee): Deleted.
2326         * runtime/JSCell.h:
2327         * runtime/JSCellInlines.h:
2328         (JSC::ExecState::vm):
2329         * runtime/JSFunction.cpp:
2330         (JSC::RetrieveArgumentsFunctor::operator()):
2331         (JSC::RetrieveCallerFunctionFunctor::operator()):
2332         * runtime/JSGlobalObject.cpp:
2333         * runtime/SamplingProfiler.cpp:
2334         (JSC::FrameWalker::recordJSFrame):
2335         (JSC::SamplingProfiler::processUnverifiedStackTraces):
2336         * runtime/SamplingProfiler.h:
2337         (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
2338         * runtime/StackFrame.cpp:
2339         (JSC::StackFrame::sourceURL):
2340         (JSC::StackFrame::functionName):
2341         * runtime/StackFrame.h:
2342         (JSC::StackFrame::wasm):
2343         * runtime/VM.cpp:
2344         (JSC::VM::VM):
2345         (JSC::VM::throwException):
2346         * runtime/VM.h:
2347         * wasm/JSWebAssembly.h:
2348         * wasm/WasmB3IRGenerator.cpp:
2349         * wasm/WasmBinding.cpp:
2350         (JSC::Wasm::wasmToWasm):
2351         * wasm/WasmCallee.cpp: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.cpp.
2352         (JSC::Wasm::Callee::Callee):
2353         (JSC::JSWebAssemblyCallee::JSWebAssemblyCallee): Deleted.
2354         (JSC::JSWebAssemblyCallee::finishCreation): Deleted.
2355         (JSC::JSWebAssemblyCallee::destroy): Deleted.
2356         * wasm/WasmCallee.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyCallee.h.
2357         (JSC::Wasm::Callee::create):
2358         (JSC::JSWebAssemblyCallee::create): Deleted.
2359         (JSC::JSWebAssemblyCallee::createStructure): Deleted.
2360         (JSC::JSWebAssemblyCallee::entrypoint): Deleted.
2361         (JSC::JSWebAssemblyCallee::calleeSaveRegisters): Deleted.
2362         * wasm/WasmContext.h:
2363         * wasm/WasmPlan.cpp:
2364         * wasm/WasmPlan.h:
2365         * wasm/WasmPlanInlines.h:
2366         (JSC::Wasm::Plan::initializeCallees):
2367         * wasm/WasmThunks.cpp:
2368         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2369         * wasm/js/JSWebAssemblyCallee.cpp: Removed.
2370         * wasm/js/JSWebAssemblyCallee.h: Removed.
2371         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2372         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
2373         (JSC::JSWebAssemblyCodeBlock::initialize):
2374         (JSC::JSWebAssemblyCodeBlock::visitChildren):
2375         * wasm/js/JSWebAssemblyCodeBlock.h:
2376         (JSC::JSWebAssemblyCodeBlock::create):
2377         (JSC::JSWebAssemblyCodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
2378         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
2379         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
2380         (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
2381         (JSC::JSWebAssemblyCodeBlock::setJSEntrypointCallee):
2382         (JSC::JSWebAssemblyCodeBlock::setWasmEntrypointCallee):
2383         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
2384         (JSC::JSWebAssemblyCodeBlock::allocationSize):
2385         (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
2386         (JSC::JSWebAssemblyCodeBlock::callees): Deleted.
2387         (JSC::JSWebAssemblyCodeBlock::offsetOfCallees): Deleted.
2388         * wasm/js/JSWebAssemblyInstance.h:
2389         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
2390         * wasm/js/JSWebAssemblyModule.cpp:
2391         * wasm/js/WebAssemblyFunction.cpp:
2392         (JSC::callWebAssemblyFunction):
2393         (JSC::WebAssemblyFunction::create):
2394         (JSC::WebAssemblyFunction::WebAssemblyFunction):
2395         (JSC::WebAssemblyFunction::visitChildren):
2396         (JSC::WebAssemblyFunction::finishCreation):
2397         * wasm/js/WebAssemblyFunction.h:
2398         (JSC::WebAssemblyFunction::wasmEntrypoint):
2399         (JSC::WebAssemblyFunction::jsEntrypoint):
2400         (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint):
2401         (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode): Deleted.
2402         * wasm/js/WebAssemblyModuleConstructor.cpp:
2403         * wasm/js/WebAssemblyModuleRecord.cpp:
2404         (JSC::WebAssemblyModuleRecord::link):
2405         (JSC::WebAssemblyModuleRecord::evaluate):
2406
2407 2017-04-04  Keith Miller  <keith_miller@apple.com>
2408
2409         WasmBench asserts in debug jsc
2410         https://bugs.webkit.org/show_bug.cgi?id=170462
2411
2412         Reviewed by Saam Barati.
2413
2414         The assertion should have been an if.
2415
2416         * wasm/WasmWorklist.cpp:
2417
2418 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2419
2420         Air::lowerAfterRegAlloc should bail early if it finds no Shuffles or ColdCCalls
2421         https://bugs.webkit.org/show_bug.cgi?id=170305
2422
2423         Reviewed by Saam Barati.
2424         
2425         This reduces and sometimes completely eliminates the need to run lowerAfterRegAlloc().
2426         
2427         This lowers the Shuffle for the arguments of a CCall before register allocation unless
2428         the CCall arguments require a real shuffle (like if the CCall arguments were argument
2429         registers). This lowers a ColdCCall like a CCall for optLevel<2.
2430         
2431         Finally, lowerAfterRegAlloc() now checks if there are any Shuffles or CCalls before it
2432         does anything else. For wasm at -O1, this means that the phase doesn't run at all. This
2433         is a ~3% wasm -O1 compile time progression.
2434         
2435         To make this easy, I changed optLevel into a property of Procedure and Code rather than
2436         an argument we thread through everything. I like how Procedure and Code are dumping
2437         ground classes. This does not bother me. Note that I cloned optLevel into Procedure and
2438         Code so that it's cheap to query inside Air phases.
2439
2440         * b3/B3Compile.cpp:
2441         (JSC::B3::compile):
2442         * b3/B3Compile.h:
2443         * b3/B3Generate.cpp:
2444         (JSC::B3::prepareForGeneration):
2445         (JSC::B3::generateToAir):
2446         * b3/B3Generate.h:
2447         * b3/B3Procedure.cpp:
2448         (JSC::B3::Procedure::setOptLevel):
2449         * b3/B3Procedure.h:
2450         (JSC::B3::Procedure::optLevel):
2451         * b3/air/AirCode.h:
2452         (JSC::B3::Air::Code::isPinned):
2453         (JSC::B3::Air::Code::setOptLevel):
2454         (JSC::B3::Air::Code::optLevel):
2455         * b3/air/AirEmitShuffle.cpp:
2456         (JSC::B3::Air::ShufflePair::bank):
2457         (JSC::B3::Air::ShufflePair::opcode):
2458         (JSC::B3::Air::ShufflePair::inst):
2459         (JSC::B3::Air::emitShuffle):
2460         * b3/air/AirEmitShuffle.h:
2461         (JSC::B3::Air::moveFor):
2462         * b3/air/AirGenerate.cpp:
2463         (JSC::B3::Air::prepareForGeneration):
2464         * b3/air/AirGenerate.h:
2465         * b3/air/AirLowerAfterRegAlloc.cpp:
2466         (JSC::B3::Air::lowerAfterRegAlloc):
2467         * b3/air/AirLowerMacros.cpp:
2468         (JSC::B3::Air::lowerMacros):
2469         * b3/testb3.cpp:
2470         (JSC::B3::compileProc):
2471         * wasm/WasmB3IRGenerator.cpp:
2472         (JSC::Wasm::parseAndCompile):
2473
2474 2017-04-04  Filip Pizlo  <fpizlo@apple.com>
2475
2476         Don't need to Air::reportUsedRegisters for wasm at -O1
2477         https://bugs.webkit.org/show_bug.cgi?id=170459
2478
2479         Reviewed by Saam Barati.
2480         
2481         I did some refactorings to Liveness<> to try to understand its performance. Based on
2482         this I concluded that the bigger immediate issue is just removing unnecessary phases
2483         from -O1.
2484         
2485         This removes Air::reportUsedRegisters() from -O1 if the user has indicated that he is
2486         not interested in StackmapGenerationParams::usedRegisters(). The logic here is a bit
2487         weird because of how Air does spill code generation. The register allocator's spiller
2488         will emit spill code using identifiable spill slots, which allows subsequent phases to
2489         register-allocate the spill slots. We do this by a forward flow CSE phase called
2490         fixObviousSpills (which is a terrible name since there is no longer anything obvious
2491         about some of the spills that this phase can fix!). As is most natural for CSEs over
2492         3AC, it rewires the uses of redundant computations rather than removing the redundant
2493         computations. This means that if a spill got "fixed", there may be either or both of
2494         the following:
2495         
2496         - Dead loads from the stack.
2497         - Dead stores to the stack.
2498         
2499         We know that a load from the stack is dead if the register is dead at the point of the
2500         load. We know that a store to the stack is dead if the spill slot is dead at the point
2501         of the store.
2502         
2503         Unfortunately, liveness analysis - over either registers or spill slots - is expensive.
2504         
2505         Fortunately, allocateStack() already does liveness analysis over spill slots. So, we
2506         baked elimination of stores to the stack into that phase. That aspect of clean-up after
2507         the spill CSE comes for free.
2508         
2509         Also fortunately for the FTL, we have to do reportUsedRegisters() anyway. This is a
2510         phase that enables StackmapGenerationParams::usedRegisters() to work, which then
2511         enables the FTL's patchpoints to do crazy slow-path live range splitting. So, Air's
2512         strategy for the load fix-up after spill CSE is to do it as part of
2513         reportUsedRegisters().
2514         
2515         This patch introduces the Procedure::setNeedsUsedRegisters() API. But if you set
2516         needsUsedRegisters to false then we will still run reportUsedRegisters() at -O2 as an
2517         optimization - it removes dead loads from the stack that are left behind from
2518         fixObviousSpills().
2519         
2520         This is a ~6% compile time progression at -O1.
2521
2522         * b3/B3Procedure.h:
2523         (JSC::B3::Procedure::setNeedsUsedRegisters):
2524         (JSC::B3::Procedure::needsUsedRegisters):
2525         * b3/B3StackmapGenerationParams.h:
2526         * b3/B3VariableLiveness.cpp:
2527         (JSC::B3::VariableLiveness::VariableLiveness):
2528         * b3/air/AirCode.cpp:
2529         (JSC::B3::Air::Code::needsUsedRegisters):
2530         * b3/air/AirCode.h:
2531         * b3/air/AirGenerate.cpp:
2532         (JSC::B3::Air::prepareForGeneration):
2533         * b3/air/AirLiveness.h:
2534         (JSC::B3::Air::Liveness::Liveness):
2535         * wasm/WasmB3IRGenerator.cpp:
2536         (JSC::Wasm::parseAndCompile):
2537
2538 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
2539
2540         Air liveness should build constraints and solve them rather than repeatedly parsing IR
2541         https://bugs.webkit.org/show_bug.cgi?id=170421
2542
2543         Reviewed by Saam Barati.
2544         
2545         Inst::forEach<> is expensive. The LivenessAdapter uses forEach with a particularly
2546         gnarly lambda that has many extra checks. Therefore, a lot of the time spent in
2547         liveness analysis is just recomputing forEach<> and that lambda to get uses and defs.
2548         
2549         This introduces LivenessConstraints<>, which is a liveness constraint system based on
2550         Adapter. It basically caches the results of doing forEach. It'll give you the uses and
2551         defs at each instruction boundary.
2552         
2553         This is a ~5% compile time progression at optLevel=1. It's also a ~3% compile time
2554         progression at optLevel=2.
2555         
2556         * JavaScriptCore.xcodeproj/project.pbxproj:
2557         * b3/air/AirLivenessAdapter.h:
2558         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
2559         (JSC::B3::Air::LivenessAdapter::forEachUse):
2560         (JSC::B3::Air::LivenessAdapter::forEachDef):
2561         * b3/air/AirLivenessConstraints.h: Added.
2562         (JSC::B3::Air::LivenessConstraints::Actions::Actions):
2563         (JSC::B3::Air::LivenessConstraints::LivenessConstraints):
2564         (JSC::B3::Air::LivenessConstraints::at):
2565
2566 2017-04-03  Mark Lam  <mark.lam@apple.com>
2567
2568         Fix incorrect capacity delta calculation reported in SparseArrayValueMap::add().
2569         https://bugs.webkit.org/show_bug.cgi?id=170412
2570         <rdar://problem/29697336>
2571
2572         Reviewed by Filip Pizlo.
2573
2574         Here's an example of code that will trigger underflow in the "deprecatedExtraMemory"
2575         reported by SparseArrayValueMap::add() that is added to Heap::m_deprecatedExtraMemorySize:
2576         
2577             arr = new Array;
2578             Object.defineProperty(arr, 18, ({writable: true, configurable: true}));
2579             for (var i = 0; i < 3; ++i) {
2580                 Array.prototype.push.apply(arr, ["", () => {}, {}]);
2581                 Array.prototype.sort.apply(arr, [() => {}, []]);
2582             }
2583
2584         However, Heap::m_deprecatedExtraMemorySize is only 1 of 3 values that are added
2585         up to form the result of Heap::extraMemorySize().  Heap::m_extraMemorySize and
2586         Heap::m_arrayBuffers.size() are the other 2.
2587
2588         While Heap::m_arrayBuffers.size() is bounded by actual allocated memory, both
2589         Heap::m_deprecatedExtraMemorySize and Heap::m_extraMemorySize are added to
2590         without any bounds checks, and they are only reset to 0 at the start of a full
2591         GC.  As a result, if we have a long sequence of eden GCs with a lot of additions
2592         to Heap::m_extraMemorySize and/or Heap::m_deprecatedExtraMemorySize, then these
2593         values could theoretically overflow.  Coupling this with the underflow from
2594         SparseArrayValueMap::add(), the result for Heap::extraMemorySize() can easily
2595         overflow.  Note: Heap::extraMemorySize() is used to compute the value
2596         currentHeapSize.
2597
2598         If multiple conditions line up just right, the above overflows can result in this
2599         debug assertion failure during an eden GC:
2600
2601             ASSERT(currentHeapSize >= m_sizeAfterLastCollect);
2602
2603         Otherwise, the effects of the overflows will only result in the computed
2604         currentHeapSize not being representative of actual memory usage, and therefore,
2605         a full GC may be triggered earlier or later than is ideal.
2606
2607         This patch ensures that SparseArrayValueMap::add() cannot underflow
2608         Heap::m_deprecatedExtraMemorySize.  It also adds overflows checks in the
2609         calculations of Heap::m_deprecatedExtraMemorySize, Heap::m_extraMemorySize, and
2610         Heap::extraMemorySize() so that their values are saturated appropriately to
2611         ensure that GC collections are triggered based on representative memory usage.
2612
2613         * heap/Heap.cpp:
2614         (JSC::Heap::deprecatedReportExtraMemorySlowCase):
2615         (JSC::Heap::extraMemorySize):
2616         (JSC::Heap::updateAllocationLimits):
2617         (JSC::Heap::reportExtraMemoryVisited):
2618         * runtime/SparseArrayValueMap.cpp:
2619         (JSC::SparseArrayValueMap::add):
2620
2621 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
2622
2623         Move the Liveness<> adapters from AirLiveness.h to AirLivenessAdapter.h.
2624
2625         Rubber stamped by Keith Miller.
2626         
2627         This will make it easier to write other code that uses those adapters.
2628
2629         * JavaScriptCore.xcodeproj/project.pbxproj:
2630         * b3/air/AirLiveness.h:
2631         (JSC::B3::Air::LivenessAdapter::LivenessAdapter): Deleted.
2632         (JSC::B3::Air::LivenessAdapter::blockSize): Deleted.
2633         (JSC::B3::Air::LivenessAdapter::forEachUse): Deleted.
2634         (JSC::B3::Air::LivenessAdapter::forEachDef): Deleted.
2635         (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter): Deleted.
2636         (JSC::B3::Air::TmpLivenessAdapter::numIndices): Deleted.
2637         (JSC::B3::Air::TmpLivenessAdapter::acceptsBank): Deleted.
2638         (JSC::B3::Air::TmpLivenessAdapter::acceptsRole): Deleted.
2639         (JSC::B3::Air::TmpLivenessAdapter::valueToIndex): Deleted.
2640         (JSC::B3::Air::TmpLivenessAdapter::indexToValue): Deleted.
2641         (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter): Deleted.
2642         (JSC::B3::Air::StackSlotLivenessAdapter::numIndices): Deleted.
2643         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank): Deleted.
2644         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole): Deleted.
2645         (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex): Deleted.
2646         (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue): Deleted.
2647         * b3/air/AirLivenessAdapter.h: Added.
2648         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
2649         (JSC::B3::Air::LivenessAdapter::blockSize):
2650         (JSC::B3::Air::LivenessAdapter::forEachUse):
2651         (JSC::B3::Air::LivenessAdapter::forEachDef):
2652         (JSC::B3::Air::TmpLivenessAdapter::TmpLivenessAdapter):
2653         (JSC::B3::Air::TmpLivenessAdapter::numIndices):
2654         (JSC::B3::Air::TmpLivenessAdapter::acceptsBank):
2655         (JSC::B3::Air::TmpLivenessAdapter::acceptsRole):
2656         (JSC::B3::Air::TmpLivenessAdapter::valueToIndex):
2657         (JSC::B3::Air::TmpLivenessAdapter::indexToValue):
2658         (JSC::B3::Air::StackSlotLivenessAdapter::StackSlotLivenessAdapter):
2659         (JSC::B3::Air::StackSlotLivenessAdapter::numIndices):
2660         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsBank):
2661         (JSC::B3::Air::StackSlotLivenessAdapter::acceptsRole):
2662         (JSC::B3::Air::StackSlotLivenessAdapter::valueToIndex):
2663         (JSC::B3::Air::StackSlotLivenessAdapter::indexToValue):
2664
2665 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
2666
2667         WTF::Liveness should have an API that focuses on actions at instruction boundaries
2668         https://bugs.webkit.org/show_bug.cgi?id=170407
2669
2670         Reviewed by Keith Miller.
2671         
2672         Adopt changes to the WTF::Liveness<> API. Instead of having separate functions for the
2673         early/late versions of uses and defs, we now have just a use/def API. Those
2674         automatically take care of eary/late issues as needed.
2675         
2676         This reduces the API surface between WTF::Liveness<> and its clients, which makes it
2677         easier to implement some other optimizations I'm thinking about.
2678
2679         * b3/B3VariableLiveness.h:
2680         (JSC::B3::VariableLivenessAdapter::forEachUse):
2681         (JSC::B3::VariableLivenessAdapter::forEachDef):
2682         (JSC::B3::VariableLivenessAdapter::forEachEarlyUse): Deleted.
2683         (JSC::B3::VariableLivenessAdapter::forEachLateUse): Deleted.
2684         (JSC::B3::VariableLivenessAdapter::forEachEarlyDef): Deleted.
2685         (JSC::B3::VariableLivenessAdapter::forEachLateDef): Deleted.
2686         * b3/air/AirLiveness.h:
2687         (JSC::B3::Air::LivenessAdapter::blockSize):
2688         (JSC::B3::Air::LivenessAdapter::forEachUse):
2689         (JSC::B3::Air::LivenessAdapter::forEachDef):
2690         (JSC::B3::Air::LivenessAdapter::forEachEarlyUse): Deleted.
2691         (JSC::B3::Air::LivenessAdapter::forEachLateUse): Deleted.
2692         (JSC::B3::Air::LivenessAdapter::forEachEarlyDef): Deleted.
2693         (JSC::B3::Air::LivenessAdapter::forEachLateDef): Deleted.
2694
2695 2017-04-03  Filip Pizlo  <fpizlo@apple.com>
2696
2697         Inst::forEachArg could compile to more compact code
2698         https://bugs.webkit.org/show_bug.cgi?id=170406
2699
2700         Reviewed by Sam Weinig.
2701         
2702         Prior to this change, Inst::forEachArg compiled to a ginormous ALWAYS_INLINE switch statement.
2703         It had one case for each opcode, and then each of those cases would have a switch statement over
2704         the number of operands. Then the cases of that switch statement would have a sequence of calls to
2705         the passed lambda. This meant that every user of forEachArg would generate an insane amount of
2706         code. It also meant that the inlining achieved nothing, since the lambda would surely then not
2707         be inlined - and if it was, then the icache pressure due to code bloat would surely negate any
2708         benefits.
2709         
2710         This replaces that code with a loop over a compact look-up table. We use the opcode and number of
2711         operands as keys into that look-up table. The table only takes about 20KB. It has one byte for
2712         each argument in each overload of each opcode.
2713         
2714         I can't measure any reproducible change in performance, but the JavaScriptCore framework binary
2715         shrinks by 2.7 MB. This is a 15% reduction in JavaScriptCore binary size.
2716
2717         * JavaScriptCore.xcodeproj/project.pbxproj:
2718         * b3/B3Width.h:
2719         * b3/air/AirCustom.h:
2720         (JSC::B3::Air::PatchCustom::forEachArg):
2721         * b3/air/AirFormTable.h: Added.
2722         (JSC::B3::Air::decodeFormRole):
2723         (JSC::B3::Air::decodeFormBank):
2724         (JSC::B3::Air::decodeFormWidth):
2725         * b3/air/AirInst.h:
2726         * b3/air/opcode_generator.rb:
2727
2728 2017-04-03  Keith Miller  <keith_miller@apple.com>
2729
2730         WebAssembly: remove lastAllocatedMode from Memory
2731         https://bugs.webkit.org/show_bug.cgi?id=170405
2732
2733         Reviewed by Mark Lam.
2734
2735         It's not used anymore so there isn't any point in keeping it around.
2736
2737         * wasm/WasmMemory.cpp:
2738         (JSC::Wasm::Memory::createImpl):
2739         (JSC::Wasm::Memory::lastAllocatedMode): Deleted.
2740         * wasm/WasmMemory.h:
2741
2742 2017-04-03  Zan Dobersek  <zdobersek@igalia.com>
2743
2744         [jsc] Add patchableJumpSize() for MIPS
2745         https://bugs.webkit.org/show_bug.cgi?id=169716
2746
2747         Reviewed by Yusuke Suzuki.
2748
2749         * assembler/MIPSAssembler.h:
2750         (JSC::MIPSAssembler::patchableJumpSize): Added.
2751         * assembler/MacroAssemblerMIPS.h:
2752         (JSC::MacroAssemblerMIPS::patchableJumpSize): Added.
2753
2754 2017-04-03  Guillaume Emont  <guijemont@igalia.com>
2755
2756         [jsc] implement MIPSAssembler::relinkJumpToNop()
2757         https://bugs.webkit.org/show_bug.cgi?id=169720
2758
2759         Reviewed by Yusuke Suzuki.
2760
2761         * assembler/MIPSAssembler.h:
2762         (JSC::MIPSAssembler::relinkJumpToNop): Added.
2763
2764 2017-04-02  Carlos Garcia Campos  <cgarcia@igalia.com>
2765
2766         Share implementation of JSRunLoopTimer::timerDidFire
2767         https://bugs.webkit.org/show_bug.cgi?id=170392
2768
2769         Reviewed by Michael Catanzaro.
2770
2771         The code is cross-platform but it's duplicated in CF and GLib implementations, it could be shared instead.
2772
2773         * runtime/JSRunLoopTimer.cpp:
2774         (JSC::JSRunLoopTimer::timerDidFire): Move common implementation here.
2775         (JSC::JSRunLoopTimer::setRunLoop): Use timerDidFireCallback.
2776         (JSC::JSRunLoopTimer::timerDidFireCallback): Call JSRunLoopTimer::timerDidFire().
2777         * runtime/JSRunLoopTimer.h:
2778
2779 2017-04-01  Oleksandr Skachkov  <gskachkov@gmail.com>
2780
2781         Object with numerical keys with gaps gets filled by NaN values
2782         https://bugs.webkit.org/show_bug.cgi?id=164412
2783
2784         Reviewed by Mark Lam.
2785
2786         This patch fixes issue when object have two properties 
2787         with name as number. The issue appears when during invoking 
2788         convertDoubleToArrayStorage, array is filled by pNaN and 
2789         method converting it to real NaN. This happeneds because a 
2790         pNaN in a Double array is a hole, and Double arrays cannot 
2791         have NaN values. To fix issue we need to check value and 
2792         clear it if it pNaN.
2793
2794         * runtime/JSObject.cpp:
2795         (JSC::JSObject::convertDoubleToArrayStorage):
2796
2797 2017-03-31  Saam Barati  <sbarati@apple.com>
2798
2799         WebAssembly: Make our calls out to JS PIC friendly
2800         https://bugs.webkit.org/show_bug.cgi?id=170261
2801
2802         Reviewed by Keith Miller.
2803
2804         This patch removes a direct call from the module to the Wasm to JS stub.
2805         Instead, we do an indirect call to the stub by loading the stub's executable
2806         address off of the CodeBlock. This is to make the code we emit for comply with
2807         requirements needed for PIC.
2808         
2809         Adding this indirection is not ideal. Although this patch is neutral on
2810         WasmBench, we really want to get back to a world where we have an IC
2811         call infrastructure. This patch is obviously a regression on some
2812         types of programs. I've filed this bug to make sure we implement a
2813         PIC compliant Wasm to JS call IC:
2814         https://bugs.webkit.org/show_bug.cgi?id=170375
2815
2816         * wasm/WasmB3IRGenerator.cpp:
2817         * wasm/WasmFormat.h:
2818         * wasm/WasmPlan.cpp:
2819         (JSC::Wasm::Plan::complete):
2820         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2821         (JSC::JSWebAssemblyCodeBlock::initialize):
2822         * wasm/js/JSWebAssemblyCodeBlock.h:
2823         (JSC::JSWebAssemblyCodeBlock::create):
2824         (JSC::JSWebAssemblyCodeBlock::offsetOfImportWasmToJSStub):
2825         (JSC::JSWebAssemblyCodeBlock::offsetOfCallees):
2826         (JSC::JSWebAssemblyCodeBlock::allocationSize):
2827         (JSC::JSWebAssemblyCodeBlock::importWasmToJSStub):
2828         * wasm/js/JSWebAssemblyInstance.cpp:
2829         (JSC::JSWebAssemblyInstance::addUnitializedCodeBlock):
2830         * wasm/js/JSWebAssemblyInstance.h:
2831         (JSC::JSWebAssemblyInstance::offsetOfCodeBlock):
2832
2833 2017-03-31  Keith Miller  <keith_miller@apple.com>
2834
2835         WebAssembly: webAssemblyB3OptimizationLevel should use defaultB3OptLevel by default
2836         https://bugs.webkit.org/show_bug.cgi?id=170378
2837
2838         Reviewed by Saam Barati.
2839
2840         * runtime/Options.h:
2841         * wasm/WasmB3IRGenerator.h:
2842
2843 2017-03-31  Keith Miller  <keith_miller@apple.com>
2844
2845         WebAssembly: Add compilation level option
2846         https://bugs.webkit.org/show_bug.cgi?id=170374
2847
2848         Reviewed by Mark Lam.
2849
2850         This patch adds an option, webAssemblyB3OptimizationLevel, which
2851         changes the optimization mode wasm passes to B3.
2852
2853         * runtime/Options.h:
2854         * wasm/WasmPlan.cpp:
2855         (JSC::Wasm::Plan::compileFunctions):
2856
2857 2017-03-31  Saam Barati  <sbarati@apple.com>
2858
2859         WebAssembly: Strip WasmParser and WasmFunctionParser from knowing about VM
2860         https://bugs.webkit.org/show_bug.cgi?id=170312
2861
2862         Reviewed by Mark Lam.
2863
2864         This is another step towards PIC-ifying Wasm. This patch removes
2865         the VM field that is no longer used.
2866
2867         * wasm/WasmB3IRGenerator.cpp:
2868         (JSC::Wasm::parseAndCompile):
2869         * wasm/WasmB3IRGenerator.h:
2870         * wasm/WasmFunctionParser.h:
2871         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
2872         * wasm/WasmModuleParser.h:
2873         (JSC::Wasm::ModuleParser::ModuleParser):
2874         * wasm/WasmParser.h:
2875         (JSC::Wasm::Parser<SuccessType>::Parser):
2876         * wasm/WasmPlan.cpp:
2877         (JSC::Wasm::Plan::parseAndValidateModule):
2878         (JSC::Wasm::Plan::compileFunctions):
2879         * wasm/WasmValidate.cpp:
2880         (JSC::Wasm::validateFunction):
2881         * wasm/WasmValidate.h:
2882
2883 2017-03-31  Saam Barati  <sbarati@apple.com>
2884
2885         WebAssembly: Ref count Signature and SignatureInformation should not care about VM
2886         https://bugs.webkit.org/show_bug.cgi?id=170316
2887
2888         Reviewed by Keith Miller.
2889
2890         This is yet again another step towards PIC-ifying Wasm.
2891         Signature should be ref counted so we can tell when
2892         no code is holding onto a Signature. This makes it easy
2893         to free unused Signatures. Also, this patch rids SignatureInfo
2894         of any VM knowledge. Now, there is just a single SignatureInfo that
2895         lives in a process.
2896
2897         * runtime/VM.h:
2898         * wasm/WasmB3IRGenerator.cpp:
2899         (JSC::Wasm::createJSToWasmWrapper):
2900         (JSC::Wasm::parseAndCompile):
2901         * wasm/WasmB3IRGenerator.h:
2902         * wasm/WasmBinding.cpp:
2903         (JSC::Wasm::wasmToJs):
2904         * wasm/WasmCallingConvention.h:
2905         (JSC::Wasm::CallingConvention::loadArguments):
2906         * wasm/WasmFormat.h:
2907         * wasm/WasmFunctionParser.h:
2908         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
2909         * wasm/WasmModuleParser.cpp:
2910         * wasm/WasmPlan.cpp:
2911         (JSC::Wasm::Plan::parseAndValidateModule):
2912         (JSC::Wasm::Plan::compileFunctions):
2913         (JSC::Wasm::Plan::complete):
2914         * wasm/WasmSignature.cpp:
2915         (JSC::Wasm::Signature::hash):
2916         (JSC::Wasm::Signature::tryCreate):
2917         (JSC::Wasm::SignatureInformation::SignatureInformation):
2918         (JSC::Wasm::SignatureInformation::singleton):
2919         (JSC::Wasm::SignatureInformation::adopt):
2920         (JSC::Wasm::SignatureInformation::get):
2921         (JSC::Wasm::SignatureInformation::tryCleanup):
2922         (JSC::Wasm::Signature::create): Deleted.
2923         (JSC::Wasm::Signature::createInvalid): Deleted.
2924         (JSC::Wasm::Signature::destroy): Deleted.
2925         (JSC::Wasm::SignatureInformation::~SignatureInformation): Deleted.
2926         * wasm/WasmSignature.h:
2927         (JSC::Wasm::Signature::allocatedSize):
2928         (JSC::Wasm::Signature::operator==):
2929         * wasm/WasmValidate.cpp:
2930         (JSC::Wasm::validateFunction):
2931         * wasm/WasmValidate.h:
2932         * wasm/js/JSWebAssemblyModule.cpp:
2933         (JSC::JSWebAssemblyModule::destroy):
2934         * wasm/js/WebAssemblyFunction.cpp:
2935         (JSC::callWebAssemblyFunction):
2936         * wasm/js/WebAssemblyFunction.h:
2937         * wasm/js/WebAssemblyModuleRecord.cpp:
2938         (JSC::WebAssemblyModuleRecord::link):
2939         (JSC::WebAssemblyModuleRecord::evaluate):
2940         * wasm/js/WebAssemblyWrapperFunction.cpp:
2941         (JSC::WebAssemblyWrapperFunction::create):
2942         * wasm/js/WebAssemblyWrapperFunction.h:
2943
2944 2017-03-31  Mark Lam  <mark.lam@apple.com>
2945
2946         Array.prototype.splice() should not be using JSArray::tryCreateForInitializationPrivate().
2947         https://bugs.webkit.org/show_bug.cgi?id=170303
2948         <rdar://problem/31358281>
2949
2950         Reviewed by Filip Pizlo.
2951
2952         This is because it needs to call getProperty() later to get the values for
2953         initializing the array.  getProperty() can execute arbitrary code and potentially
2954         trigger the GC.  This is not allowed for clients of JSArray::tryCreateForInitializationPrivate().
2955
2956         * runtime/ArrayPrototype.cpp:
2957         (JSC::arrayProtoFuncSplice):
2958         (JSC::copySplicedArrayElements): Deleted.
2959
2960 2017-03-31  Oleksandr Skachkov  <gskachkov@gmail.com>
2961
2962         String.prototype.replace incorrectly applies "special replacement parameters" when passed a function
2963         https://bugs.webkit.org/show_bug.cgi?id=170151
2964
2965         Reviewed by Saam Barati.
2966
2967         This patch fixes issue for String.prototype.replace when passed a function 
2968         with special symbols "$$". It happeneds because substituteBackreferences applies 
2969         unconditionally, but according to the spec it should be applied only for text 
2970         21.1.3.16.8 https://tc39.github.io/ecma262/#sec-string.prototype.replace
2971
2972         * runtime/StringPrototype.cpp:
2973         (JSC::replaceUsingStringSearch):
2974
2975 2017-03-30  Saam Barati  <sbarati@apple.com>
2976
2977         WebAssembly: When Wasm calls to C, it should use Wasm::Context* instead of ExecState* to get VM
2978         https://bugs.webkit.org/show_bug.cgi?id=170185
2979
2980         Reviewed by Michael Saboff.
2981
2982         This is one more step in the direction of PIC-ified Wasm.
2983         When we lift WasmCallee above VM, we will no longer be
2984         able to get VM from ExecState*. This patch ensures that
2985         we don't do that from within the Wasm runtime. Instead,
2986         we use the Wasm::Context* to get the VM.
2987
2988         This patch also adds a new class, Wasm::Thunks. There
2989         is a single Wasm::Thunks that lives in the process. It
2990         is responsible for generating a thunk that Wasm relies on.
2991         The only such thunk right now is the exception throwing
2992         thunk.
2993
2994         This patch also rids WasmFaultSignalHandler from any knowledge
2995         of VM. Previously, it relied on VM to get the exception handling
2996         thunk.
2997
2998         The only part of the Wasm runtime that will be allowed
2999         to get VM& from ExecState will be WasmBinding. In the
3000         future, we plan to keep the calls out to JS to keep
3001         a JSCell as the callee.
3002
3003         * JavaScriptCore.xcodeproj/project.pbxproj:
3004         * dfg/DFGOSREntry.cpp:
3005         (JSC::DFG::prepareOSREntry):
3006         * ftl/FTLOSRExitCompiler.cpp:
3007         (JSC::FTL::compileStub):
3008         * interpreter/Interpreter.cpp:
3009         (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
3010         * jit/AssemblyHelpers.cpp:
3011         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
3012         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBufferImpl):
3013         * jit/AssemblyHelpers.h:
3014         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
3015         * jit/ThunkGenerators.cpp:
3016         (JSC::throwExceptionFromWasmThunkGenerator): Deleted.
3017         * jit/ThunkGenerators.h:
3018         * runtime/InitializeThreading.cpp:
3019         (JSC::initializeThreading):
3020         * runtime/VM.cpp:
3021         (JSC::VM::VM):
3022         (JSC::VM::getAllCalleeSaveRegisterOffsets):
3023         * runtime/VM.h:
3024         (JSC::VM::topVMEntryFrameOffset):
3025         (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
3026         * wasm/WasmB3IRGenerator.cpp:
3027         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
3028         * wasm/WasmFaultSignalHandler.cpp:
3029         (JSC::Wasm::trapHandler):
3030         * wasm/WasmMemory.cpp:
3031         (JSC::Wasm::tryGetFastMemory):
3032         * wasm/WasmThunks.cpp: Added.
3033         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
3034         (JSC::Wasm::Thunks::initialize):
3035         (JSC::Wasm::Thunks::singleton):
3036         (JSC::Wasm::Thunks::stub):
3037         (JSC::Wasm::Thunks::existingStub):
3038         * wasm/WasmThunks.h: Added.
3039         * wasm/js/JSWebAssemblyInstance.cpp:
3040         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
3041         * wasm/js/JSWebAssemblyInstance.h:
3042         (JSC::JSWebAssemblyInstance::offsetOfVM):
3043         * wasm/js/JSWebAssemblyMemory.cpp:
3044         (JSC::JSWebAssemblyMemory::grow):
3045         * wasm/js/JSWebAssemblyMemory.h:
3046         * wasm/js/WebAssemblyMemoryPrototype.cpp:
3047         (JSC::webAssemblyMemoryProtoFuncGrow):
3048
3049 2017-03-30  Mark Lam  <mark.lam@apple.com>
3050
3051         IntlObject should not be using JSArray::initializeIndex().
3052         https://bugs.webkit.org/show_bug.cgi?id=170302
3053         <rdar://problem/31356918>
3054
3055         Reviewed by Saam Barati.
3056
3057         JSArray::initializeIndex() is only meant to be used with arrays created using
3058         JSArray::tryCreateForInitializationPrivate() under very constrained conditions.
3059
3060         * runtime/IntlObject.cpp:
3061         (JSC::canonicalizeLocaleList):
3062         (JSC::intlObjectFuncGetCanonicalLocales):
3063
3064 2017-03-30  Filip Pizlo  <fpizlo@apple.com>
3065
3066         Air should support linear scan for optLevel<2
3067         https://bugs.webkit.org/show_bug.cgi?id=170161
3068
3069         Reviewed by Saam Barati.
3070         
3071         This changes the default opt level of B3 to 2. It makes the other opt levels useful by adding a
3072         new register allocator. This new linear scan allocator will produce significantly worse code.
3073         But it will produce that code a lot faster than IRC or Briggs.
3074         
3075         The opt levels are:
3076             0: no optimizations, linear scan
3077             1: some optimizations, linear scan
3078             2: full optimizations, graph coloring (IRC or Briggs based on CPU)
3079         
3080         What we used to call optLevel=1 is not called optLevel=2, or better yet,
3081         optLevel=B3::defaultOptLevel(). We no longer have anything like the old optLevel=0 (which did no
3082         optimizations but ran graph coloring).
3083         
3084         allocateRegistersByLinearScan() faithfully implements Massimiliano Poletto and Vivek Sarkar's
3085         famous algorithm. It uses the variant that handles clobbered registers by avoiding assigning
3086         ranges to those registers if the range overlaps a clobber. It's engineered to allocate registers
3087         very quickly and generate inefficient code without falling off a cliff.
3088         
3089         The new optLevel=1 speeds up B3 by a factor of 2, and results in a 80% throughput regression.
3090         Linear scan runs 4.7x faster than graph coloring on average.
3091
3092         * CMakeLists.txt:
3093         * JavaScriptCore.xcodeproj/project.pbxproj:
3094         * b3/B3BasicBlockUtils.h:
3095         (JSC::B3::blocksInPreOrder):
3096         (JSC::B3::blocksInPostOrder):
3097         * b3/B3BlockWorklist.h:
3098         * b3/B3CFG.h:
3099         (JSC::B3::CFG::newMap):
3100         * b3/B3Common.h:
3101         (JSC::B3::defaultOptLevel):
3102         * b3/B3Compile.h:
3103         * b3/B3DuplicateTails.cpp:
3104         * b3/B3EliminateCommonSubexpressions.cpp:
3105         * b3/B3FixSSA.cpp:
3106         (JSC::B3::demoteValues):
3107         (JSC::B3::fixSSA):
3108         * b3/B3FixSSA.h:
3109         * b3/B3Generate.cpp:
3110         (JSC::B3::prepareForGeneration):
3111         (JSC::B3::generateToAir):
3112         * b3/B3Generate.h:
3113         * b3/B3HeapRange.cpp: Removed.
3114         * b3/B3HeapRange.h:
3115         (JSC::B3::HeapRange::HeapRange): Deleted.
3116         (JSC::B3::HeapRange::top): Deleted.
3117         (JSC::B3::HeapRange::operator==): Deleted.
3118         (JSC::B3::HeapRange::operator!=): Deleted.
3119         (JSC::B3::HeapRange::operator|): Deleted.
3120         (JSC::B3::HeapRange::operator bool): Deleted.
3121         (JSC::B3::HeapRange::begin): Deleted.
3122         (JSC::B3::HeapRange::end): Deleted.
3123         (JSC::B3::HeapRange::overlaps): Deleted.
3124         * b3/B3LowerToAir.cpp:
3125         * b3/B3MoveConstants.cpp:
3126         * b3/B3PhiChildren.h:
3127         * b3/B3Procedure.cpp:
3128         (JSC::B3::Procedure::dump):
3129         (JSC::B3::Procedure::deleteOrphans):
3130         (JSC::B3::Procedure::setBlockOrderImpl):
3131         * b3/B3ReduceDoubleToFloat.cpp:
3132         * b3/B3ReduceStrength.cpp:
3133         * b3/B3SSACalculator.h:
3134         * b3/B3UseCounts.h:
3135         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
3136         * b3/air/AirAllocateRegistersByLinearScan.cpp: Added.
3137         (JSC::B3::Air::allocateRegistersByLinearScan):
3138         * b3/air/AirAllocateRegistersByLinearScan.h: Added.
3139         * b3/air/AirAllocateStack.cpp:
3140         (JSC::B3::Air::allocateStack):
3141         * b3/air/AirArg.cpp:
3142         (WTF::printInternal):
3143         * b3/air/AirArg.h:
3144         (JSC::B3::Air::Arg::activeAt):
3145         (JSC::B3::Air::Arg::timing):
3146         (JSC::B3::Air::Arg::forEachPhase):
3147         * b3/air/AirBasicBlock.h:
3148         * b3/air/AirBlockWorklist.h:
3149         * b3/air/AirCFG.h:
3150         (JSC::B3::Air::CFG::newMap):
3151         * b3/air/AirEliminateDeadCode.cpp:
3152         (JSC::B3::Air::eliminateDeadCode):
3153         * b3/air/AirFixObviousSpills.cpp:
3154         * b3/air/AirFixPartialRegisterStalls.cpp:
3155         (JSC::B3::Air::fixPartialRegisterStalls):
3156         * b3/air/AirFixSpillsAfterTerminals.cpp: Added.
3157         (JSC::B3::Air::fixSpillsAfterTerminals):
3158         * b3/air/AirFixSpillsAfterTerminals.h: Added.
3159         * b3/air/AirGenerate.cpp:
3160         (JSC::B3::Air::prepareForGeneration):
3161         (JSC::B3::Air::generate):
3162         * b3/air/AirGenerate.h:
3163         * b3/air/AirGenerationContext.h:
3164         * b3/air/AirInsertionSet.h:
3165         * b3/air/AirInst.cpp:
3166         (JSC::B3::Air::Inst::needsPadding):
3167         * b3/air/AirLowerAfterRegAlloc.cpp:
3168         (JSC::B3::Air::lowerAfterRegAlloc):
3169         * b3/air/AirLowerEntrySwitch.cpp:
3170         (JSC::B3::Air::lowerEntrySwitch):
3171         * b3/air/AirOpcode.opcodes:
3172         * b3/air/AirPhaseInsertionSet.cpp: Added.
3173         (JSC::B3::Air::PhaseInsertionSet::execute):
3174         * b3/air/AirPhaseInsertionSet.h: Added.
3175         (JSC::B3::Air::PhaseInsertion::PhaseInsertion):
3176         (JSC::B3::Air::PhaseInsertion::phase):
3177         (JSC::B3::Air::PhaseInsertion::operator<):
3178         (JSC::B3::Air::PhaseInsertionSet::PhaseInsertionSet):
3179         (JSC::B3::Air::PhaseInsertionSet::appendInsertion):
3180         (JSC::B3::Air::PhaseInsertionSet::insertInst):
3181         (JSC::B3::Air::PhaseInsertionSet::insert):
3182         * b3/air/AirRegLiveness.h:
3183         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
3184         * b3/air/AirSpillEverything.cpp:
3185         (JSC::B3::Air::spillEverything):
3186         * b3/air/AirTmp.cpp:
3187         * b3/air/AirTmp.h:
3188         (JSC::B3::Air::Tmp::tmpForIndex):
3189         * b3/air/AirTmpInlines.h:
3190         (JSC::B3::Air::Tmp::Indexed::Indexed):
3191         (JSC::B3::Air::Tmp::Indexed::index):
3192         (JSC::B3::Air::Tmp::AbsolutelyIndexed::AbsolutelyIndexed):
3193         (JSC::B3::Air::Tmp::AbsolutelyIndexed::index):
3194         (JSC::B3::Air::Tmp::indexed):
3195         (JSC::B3::Air::Tmp::absolutelyIndexed):
3196         (JSC::B3::Air::Tmp::tmpForAbsoluteIndex):
3197         * b3/testb3.cpp:
3198         (JSC::B3::compile):
3199         (JSC::B3::testMulLoadTwice):
3200         * jit/RegisterSet.h:
3201         (JSC::RegisterSet::add):
3202         (JSC::RegisterSet::remove):
3203         * runtime/Options.h:
3204         * wasm/WasmB3IRGenerator.h:
3205
3206 2017-03-30  Youenn Fablet  <youenn@apple.com>
3207
3208         Clean up RTCDataChannel
3209         https://bugs.webkit.org/show_bug.cgi?id=169732
3210
3211         Reviewed by Chris Dumez.
3212
3213         * runtime/CommonIdentifiers.h: Adding RTCDataChannelEvent.
3214
3215 2017-03-30  Saam Barati  <sbarati@apple.com>
3216
3217         WebAssembly: pass Wasm::Context* to vmEntryToWasm when not using fast TLS
3218         https://bugs.webkit.org/show_bug.cgi?id=170182
3219
3220         Reviewed by Mark Lam.
3221
3222         This is one more step in the direction of PIC-ified Wasm.
3223         I'm removing assumptions that a wasm callee is a cell. We used to use
3224         the callee to get the WasmContext off the callee's VM. Instead,
3225         this patch makes it so that we pass in the context as a parameter
3226         to the JS entrypoint.
3227
3228         * heap/MarkedBlock.h:
3229         (JSC::MarkedBlock::offsetOfVM): Deleted.
3230         * jit/AssemblyHelpers.cpp:
3231         (JSC::AssemblyHelpers::loadWasmContext):
3232         (JSC::AssemblyHelpers::storeWasmContext):
3233         (JSC::AssemblyHelpers::loadWasmContextNeedsMacroScratchRegister):
3234         (JSC::AssemblyHelpers::storeWasmContextNeedsMacroScratchRegister):
3235         * jsc.cpp:
3236         (functionTestWasmModuleFunctions):
3237         * runtime/VM.h:
3238         (JSC::VM::wasmContextOffset): Deleted.
3239         * wasm/WasmB3IRGenerator.cpp:
3240         (JSC::Wasm::B3IRGenerator::materializeWasmContext):
3241         (JSC::Wasm::B3IRGenerator::restoreWasmContext):
3242         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
3243         (JSC::Wasm::createJSToWasmWrapper):
3244         * wasm/WasmContext.cpp:
3245         (JSC::Wasm::loadContext):
3246         (JSC::Wasm::storeContext):
3247         (JSC::loadWasmContext): Deleted.
3248         (JSC::storeWasmContext): Deleted.
3249         * wasm/WasmContext.h:
3250         (JSC::Wasm::useFastTLS):
3251         (JSC::Wasm::useFastTLSForContext):
3252         * wasm/WasmMemoryInformation.cpp:
3253         (JSC::Wasm::PinnedRegisterInfo::get):
3254         * wasm/WasmMemoryInformation.h:
3255         (JSC::Wasm::useFastTLS): Deleted.
3256         (JSC::Wasm::useFastTLSForWasmContext): Deleted.
3257         * wasm/js/WebAssemblyFunction.cpp:
3258         (JSC::callWebAssemblyFunction):
3259
3260 2017-03-30  JF Bastien  <jfbastien@apple.com>
3261
3262         WebAssembly: fix misc JS API implementation inconsistencies
3263         https://bugs.webkit.org/show_bug.cgi?id=170187
3264
3265         Reviewed by Keith Miller.
3266
3267         Auto-generate lookup tables.
3268         Methods should be on prototype.
3269         Exception returns should be idiomatic.
3270
3271         * wasm/JSWebAssembly.cpp: validate / compile / instantiate should
3272         be on the prototype
3273         (JSC::JSWebAssembly::create):
3274         (JSC::JSWebAssembly::finishCreation):
3275         (JSC::reject): Deleted.
3276         (JSC::webAssemblyCompileFunc): Deleted.
3277         (JSC::resolve): Deleted.
3278         (JSC::instantiate): Deleted.
3279         (JSC::compileAndInstantiate): Deleted.
3280         (JSC::webAssemblyInstantiateFunc): Deleted.
3281         (JSC::webAssemblyValidateFunc): Deleted.
3282         * wasm/JSWebAssembly.h:
3283         * wasm/js/WebAssemblyMemoryPrototype.cpp: move from JSWebAssembly.cpp
3284         (JSC::webAssemblyMemoryProtoFuncBuffer):
3285         (JSC::WebAssemblyMemoryPrototype::create):
3286         (JSC::WebAssemblyMemoryPrototype::finishCreation):
3287         * wasm/js/WebAssemblyMemoryPrototype.h:
3288         * wasm/js/WebAssemblyPrototype.cpp:
3289         (JSC::reject):
3290         (JSC::webAssemblyCompileFunc):
3291         (JSC::resolve):
3292         (JSC::instantiate):
3293         (JSC::compileAndInstantiate):
3294         (JSC::webAssemblyInstantiateFunc):
3295         (JSC::webAssemblyValidateFunc):
3296         (JSC::webAssemblyFunctionValidate): Deleted.
3297         (JSC::webAssemblyFunctionCompile): Deleted.
3298         * wasm/js/WebAssemblyTablePrototype.cpp:
3299         (JSC::webAssemblyTableProtoFuncGrow):
3300         (JSC::webAssemblyTableProtoFuncGet):
3301         (JSC::webAssemblyTableProtoFuncSet):
3302         (JSC::WebAssemblyTablePrototype::create):
3303         (JSC::WebAssemblyTablePrototype::finishCreation):
3304         * wasm/js/WebAssemblyTablePrototype.h:
3305
3306 2017-03-29  Keith Miller  <keith_miller@apple.com>
3307
3308         Unreviewed, fix the build, again. Hopefully for the last time, again!
3309
3310         * runtime/Options.cpp:
3311
3312 2017-03-29  Keith Miller  <keith_miller@apple.com>
3313
3314         Unreviewed, fix the build, again. Hopefully for the last time!
3315
3316         * runtime/Options.cpp:
3317         (JSC::parse):
3318
3319 2017-03-29  Keith Miller  <keith_miller@apple.com>
3320
3321         Unreviewed, windows build fix.
3322
3323         * runtime/Options.cpp:
3324         (JSC::parse):
3325
3326 2017-03-29  Keith Miller  <keith_miller@apple.com>
3327
3328         WebAssembly: B3IRGenerator should pool constants
3329         https://bugs.webkit.org/show_bug.cgi?id=170266
3330
3331         Reviewed by Filip Pizlo.
3332
3333         This patch adds a HashMap to B3IRGenerator that contains all the constants used in a function.
3334         B3IRGenerator then uses an InsertionSet to add all those constants to the root BB. This doesn't
3335         appear to be a compile time improvement but it could be valuable in the future.
3336
3337         * b3/B3Opcode.h:
3338         (JSC::B3::opcodeForConstant):
3339         * b3/B3Procedure.cpp:
3340         (JSC::B3::Procedure::addConstant):
3341         * b3/B3Procedure.h:
3342         * wasm/WasmB3IRGenerator.cpp:
3343         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
3344         (JSC::Wasm::B3IRGenerator::constant):
3345         (JSC::Wasm::B3IRGenerator::insertConstants):
3346         (JSC::Wasm::B3IRGenerator::addConstant):
3347         (JSC::Wasm::B3IRGenerator::dump):
3348         (JSC::Wasm::parseAndCompile):
3349         (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
3350         (JSC::Wasm::B3IRGenerator::zeroForType): Deleted.
3351         * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
3352         (generateConstCode):
3353
3354 2017-03-29  Saam Barati  <sbarati@apple.com>
3355
3356         LinkBuffer and ExecutableAllocator shouldn't have anything to do with VM
3357         https://bugs.webkit.org/show_bug.cgi?id=170210
3358
3359         Reviewed by Mark Lam.
3360
3361         This is one more step in the direction of PIC-ified Wasm.
3362         LinkBuffer and ExecutableAllocator have no business knowing about VM.
3363
3364         * assembler/LinkBuffer.cpp:
3365         (JSC::LinkBuffer::allocate):
3366         * assembler/LinkBuffer.h:
3367         (JSC::LinkBuffer::LinkBuffer):
3368         (JSC::LinkBuffer::vm): Deleted.
3369         * b3/B3Compile.cpp:
3370         (JSC::B3::compile):
3371         * b3/B3Compile.h:
3372         * b3/air/testair.cpp:
3373         * b3/testb3.cpp:
3374         (JSC::B3::compileProc):
3375         (JSC::B3::compileAndRun):
3376         (JSC::B3::testLoadAcq42):
3377         (JSC::B3::testAddArgZeroImmZDef):
3378         (JSC::B3::testAddLoadTwice):
3379         (JSC::B3::testMulLoadTwice):
3380         (JSC::B3::testMulAddArgsLeft):
3381         (JSC::B3::testMulAddArgsRight):
3382         (JSC::B3::testMulAddArgsLeft32):
3383         (JSC::B3::testMulAddArgsRight32):
3384         (JSC::B3::testMulSubArgsLeft):
3385         (JSC::B3::testMulSubArgsRight):
3386         (JSC::B3::testMulSubArgsLeft32):
3387         (JSC::B3::testMulSubArgsRight32):
3388         (JSC::B3::testMulNegArgs):
3389         (JSC::B3::testMulNegArgs32):
3390         (JSC::B3::testCompareFloatToDoubleThroughPhi):
3391         (JSC::B3::testDoubleToFloatThroughPhi):
3392         (JSC::B3::testReduceFloatToDoubleValidates):
3393         (JSC::B3::testDoubleProducerPhiToFloatConversion):
3394         (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer):
3395         (JSC::B3::testDoubleProducerPhiWithNonFloatConst):
3396         (JSC::B3::testIToD64Arg):
3397         (JSC::B3::testIToF64Arg):
3398         (JSC::B3::testIToD32Arg):
3399         (JSC::B3::testIToF32Arg):
3400         (JSC::B3::testIToD64Mem):
3401         (JSC::B3::testIToF64Mem):
3402         (JSC::B3::testIToD32Mem):
3403         (JSC::B3::testIToF32Mem):
3404         (JSC::B3::testIToDReducedToIToF64Arg):
3405         (JSC::B3::testIToDReducedToIToF32Arg):
3406         (JSC::B3::testStoreRelAddLoadAcq32):
3407         (JSC::B3::testStoreRelAddLoadAcq8):
3408         (JSC::B3::testStoreRelAddFenceLoadAcq8):
3409         (JSC::B3::testStoreRelAddLoadAcq16):
3410         (JSC::B3::testStoreRelAddLoadAcq64):
3411         (JSC::B3::testBranch):
3412         (JSC::B3::testBranchPtr):
3413         (JSC::B3::testDiamond):
3414         (JSC::B3::testBranchNotEqual):
3415         (JSC::B3::testBranchNotEqualCommute):
3416         (JSC::B3::testBranchNotEqualNotEqual):
3417         (JSC::B3::testBranchEqual):
3418         (JSC::B3::testBranchEqualEqual):
3419         (JSC::B3::testBranchEqualCommute):
3420         (JSC::B3::testBranchEqualEqual1):
3421         (JSC::B3::testBranchLoadPtr):
3422         (JSC::B3::testBranchLoad32):
3423         (JSC::B3::testBranchLoad8S):
3424         (JSC::B3::testBranchLoad8Z):
3425         (JSC::B3::testBranchLoad16S):
3426         (JSC::B3::testBranchLoad16Z):
3427         (JSC::B3::testBranch8WithLoad8ZIndex):
3428         (JSC::B3::testComplex):
3429         (JSC::B3::testSimpleCheck):
3430         (JSC::B3::testCheckFalse):
3431         (JSC::B3::testCheckTrue):
3432         (JSC::B3::testCheckLessThan):
3433         (JSC::B3::testCheckMegaCombo):
3434         (JSC::B3::testCheckTrickyMegaCombo):
3435         (JSC::B3::testCheckTwoMegaCombos):
3436         (JSC::B3::testCheckTwoNonRedundantMegaCombos):
3437         (JSC::B3::testCheckAddImm):
3438         (JSC::B3::testCheckAddImmCommute):
3439         (JSC::B3::testCheckAddImmSomeRegister):
3440         (JSC::B3::testCheckAdd):
3441         (JSC::B3::testCheckAdd64):
3442         (JSC::B3::testCheckAddFold):
3443         (JSC::B3::testCheckAddFoldFail):
3444         (JSC::B3::testCheckAddSelfOverflow64):
3445         (JSC::B3::testCheckAddSelfOverflow32):
3446         (JSC::B3::testCheckSubImm):
3447         (JSC::B3::testCheckSubBadImm):
3448         (JSC::B3::testCheckSub):
3449         (JSC::B3::testCheckSub64):
3450         (JSC::B3::testCheckSubFold):
3451         (JSC::B3::testCheckSubFoldFail):
3452         (JSC::B3::testCheckNeg):
3453         (JSC::B3::testCheckNeg64):
3454         (JSC::B3::testCheckMul):
3455         (JSC::B3::testCheckMulMemory):
3456         (JSC::B3::testCheckMul2):
3457         (JSC::B3::testCheckMul64):
3458         (JSC::B3::testCheckMulFold):
3459         (JSC::B3::testCheckMulFoldFail):
3460         (JSC::B3::testCheckMul64SShr):
3461         (JSC::B3::testSwitch):
3462         (JSC::B3::testSwitchChillDiv):
3463         (JSC::B3::testSwitchTargettingSameBlock):
3464         (JSC::B3::testSwitchTargettingSameBlockFoldPathConstant):
3465         (JSC::B3::testBasicSelect):
3466         (JSC::B3::testSelectTest):
3467         (JSC::B3::testSelectCompareDouble):
3468         (JSC::B3::testSelectDouble):
3469         (JSC::B3::testSelectDoubleTest):
3470         (JSC::B3::testSelectDoubleCompareDouble):
3471         (JSC::B3::testSelectFloatCompareFloat):
3472         (JSC::B3::testSelectFold):
3473         (JSC::B3::testSelectInvert):
3474         (JSC::B3::testCheckSelect):
3475         (JSC::B3::testCheckSelectCheckSelect):
3476         (JSC::B3::testCheckSelectAndCSE):
3477         (JSC::B3::testTrivialInfiniteLoop):
3478         (JSC::B3::testFoldPathEqual):
3479         (JSC::B3::testLShiftSelf32):
3480         (JSC::B3::testRShiftSelf32):
3481         (JSC::B3::testURShiftSelf32):
3482         (JSC::B3::testLShiftSelf64):
3483         (JSC::B3::testRShiftSelf64):
3484         (JSC::B3::testURShiftSelf64):
3485         (JSC::B3::testPatchpointDoubleRegs):
3486         (JSC::B3::testSpillDefSmallerThanUse):
3487         (JSC::B3::testSpillUseLargerThanDef):
3488         (JSC::B3::testLateRegister):
3489         (JSC::B3::testInterpreter):
3490         (JSC::B3::testEntrySwitchSimple):
3491         (JSC::B3::testEntrySwitchNoEntrySwitch):
3492         (JSC::B3::testEntrySwitchWithCommonPaths):
3493         (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
3494         (JSC::B3::testEntrySwitchLoop):
3495         (JSC::B3::testSomeEarlyRegister):
3496         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
3497         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
3498         (JSC::B3::testPatchpointTerminalReturnValue):
3499         (JSC::B3::testMemoryFence):
3500         (JSC::B3::testStoreFence):
3501         (JSC::B3::testLoadFence):
3502         (JSC::B3::testPCOriginMapDoesntInsertNops):
3503         (JSC::B3::testPinRegisters):
3504         (JSC::B3::testX86LeaAddAddShlLeft):
3505         (JSC::B3::testX86LeaAddAddShlRight):
3506         (JSC::B3::testX86LeaAddAdd):
3507         (JSC::B3::testX86LeaAddShlRight):
3508         (JSC::B3::testX86LeaAddShlLeftScale1):
3509         (JSC::B3::testX86LeaAddShlLeftScale2):
3510         (JSC::B3::testX86LeaAddShlLeftScale4):
3511         (JSC::B3::testX86LeaAddShlLeftScale8):
3512         (JSC::B3::testAddShl32):
3513         (JSC::B3::testAddShl64):
3514         (JSC::B3::testAddShl65):
3515         (JSC::B3::testLoadBaseIndexShift2):
3516         (JSC::B3::testLoadBaseIndexShift32):
3517         (JSC::B3::testOptimizeMaterialization):
3518         (JSC::B3::testAtomicWeakCAS):
3519         (JSC::B3::testAtomicStrongCAS):
3520         (JSC::B3::testAtomicXchg):
3521         (JSC::B3::testDepend32):
3522         (JSC::B3::testDepend64):
3523         (JSC::B3::testWasmBoundsCheck):
3524         (JSC::B3::testWasmAddress):
3525         (JSC::B3::run):
3526         (JSC::B3::compile): Deleted.
3527         * bytecode/PolymorphicAccess.cpp:
3528         (JSC::PolymorphicAccess::regenerate):
3529         * dfg/DFGJITCompiler.cpp:
3530         (JSC::DFG::JITCompiler::compile):
3531         (JSC::DFG::JITCompiler::compileFunction):
3532         * dfg/DFGLazyJSValue.cpp:
3533         (JSC::DFG::LazyJSValue::emit):
3534         * dfg/DFGOSRExitCompiler.cpp:
3535         * dfg/DFGSpeculativeJIT32_64.cpp:
3536         (JSC::DFG::SpeculativeJIT::emitCall):
3537         * dfg/DFGSpeculativeJIT64.cpp:
3538         (JSC::DFG::SpeculativeJIT::emitCall):
3539         * dfg/DFGThunks.cpp:
3540         (JSC::DFG::osrExitGenerationThunkGenerator):
3541         (JSC::DFG::osrEntryThunkGenerator):
3542         * ftl/FTLCompile.cpp:
3543         (JSC::FTL::compile):
3544         * ftl/FTLLazySlowPath.cpp:
3545         (JSC::FTL::LazySlowPath::generate):
3546         * ftl/FTLLink.cpp:
3547         (JSC::FTL::link):
3548         * ftl/FTLLowerDFGToB3.cpp:
3549         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
3550         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
3551         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
3552         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
3553         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
3554         * ftl/FTLOSRExitCompiler.cpp:
3555         (JSC::FTL::compileStub):
3556         * ftl/FTLOSRExitHandle.cpp:
3557         (JSC::FTL::OSRExitHandle::emitExitThunk):
3558         * ftl/FTLSlowPathCall.cpp:
3559         (JSC::FTL::SlowPathCallContext::makeCall):
3560         * ftl/FTLSlowPathCall.h:
3561         (JSC::FTL::callOperation):
3562         * ftl/FTLState.h:
3563         * ftl/FTLThunks.cpp:
3564         (JSC::FTL::genericGenerationThunkGenerator):
3565         (JSC::FTL::slowPathCallThunkGenerator):
3566         * ftl/FTLThunks.h:
3567         (JSC::FTL::generateIfNecessary):
3568         (JSC::FTL::Thunks::getSlowPathCallThunk):
3569         * jit/AssemblyHelpers.cpp:
3570         (JSC::AssemblyHelpers::emitDumbVirtualCall):
3571         * jit/AssemblyHelpers.h:
3572         * jit/ExecutableAllocator.cpp:
3573         (JSC::ExecutableAllocator::initializeAllocator):
3574         (JSC::ExecutableAllocator::singleton):
3575         (JSC::ExecutableAllocator::ExecutableAllocator):
3576         (JSC::ExecutableAllocator::allocate):
3577         * jit/ExecutableAllocator.h:
3578         * jit/JIT.cpp:
3579         (JSC::JIT::compileWithoutLinking):
3580         * jit/JITCall.cpp:
3581         (JSC::JIT::compileCallEvalSlowCase):
3582         * jit/JITMathIC.h:
3583         (JSC::JITMathIC::generateOutOfLine):
3584         * jit/JITOpcodes.cpp:
3585         (JSC::JIT::privateCompileHasIndexedProperty):
3586         * jit/JITOpcodes32_64.cpp:
3587         (JSC::JIT::privateCompileHasIndexedProperty):
3588         * jit/JITOperations.cpp:
3589         * jit/JITOperations.h:
3590         * jit/JITPropertyAccess.cpp:
3591         (JSC::JIT::stringGetByValStubGenerator):
3592         (JSC::JIT::privateCompileGetByVal):
3593         (JSC::JIT::privateCompileGetByValWithCachedId):
3594         (JSC::JIT::privateCompilePutByVal):
3595         (JSC::JIT::privateCompilePutByValWithCachedId):
3596         * jit/JITPropertyAccess32_64.cpp:
3597         (JSC::JIT::stringGetByValStubGenerator):
3598         * jit/JITStubRoutine.h:
3599         * jit/Repatch.cpp:
3600         (JSC::ftlThunkAwareRepatchCall):
3601         (JSC::linkPolymorphicCall):
3602         * jit/SpecializedThunkJIT.h:
3603         (JSC::SpecializedThunkJIT::finalize):
3604         * jit/ThunkGenerators.cpp:
3605         (JSC::throwExceptionFromCallSlowPathGenerator):
3606         (JSC::linkCallThunkGenerator):
3607         (JSC::linkPolymorphicCallThunkGenerator):
3608         (JSC::virtualThunkFor):
3609         (JSC::nativeForGenerator):
3610         (JSC::arityFixupGenerator):
3611         (JSC::unreachableGenerator):
3612         (JSC::boundThisNoArgsFunctionCallGenerator):
3613         (JSC::throwExceptionFromWasmThunkGenerator):
3614         * llint/LLIntThunks.cpp:
3615         (JSC::LLInt::generateThunkWithJumpTo):
3616         * runtime/SamplingProfiler.cpp:
3617         (JSC::SamplingProfiler::takeSample):
3618         * runtime/VM.cpp:
3619         (JSC::VM::VM):
3620         * runtime/VM.h:
3621         * runtime/VMTraps.cpp:
3622         (JSC::VMTraps::tryInstallTrapBreakpoints):
3623         * tools/VMInspector.cpp:
3624         * wasm/WasmBinding.cpp:
3625         (JSC::Wasm::wasmToJs):
3626         (JSC::Wasm::wasmToWasm):
3627         (JSC::Wasm::exitStubGenerator):
3628         * wasm/WasmPlan.cpp:
3629         (JSC::Wasm::Plan::complete):
3630         * yarr/YarrJIT.cpp:
3631         (JSC::Yarr::YarrGenerator::compile):
3632         (JSC::Yarr::jitCompile):
3633
3634 2017-03-29  Keith Miller  <keith_miller@apple.com>
3635
3636         WebAssembly: Worklist should periodically check in to see if there are higher priority jobs to do.
3637         https://bugs.webkit.org/show_bug.cgi?id=170204
3638
3639         Reviewed by Saam Barati.
3640
3641         This patch makes it so that Wasm::Plan's compileFunctions method can return periodically
3642         to its caller. The main use for this is if a user asynchronously compiles a wasm module
3643         then later synchronously compiles another module. In this case we want to be able to pause
3644         compilation of other worklists.
3645
3646         This patch also adds support for size_t Options.
3647
3648         * runtime/Options.cpp:
3649         (JSC::parse):
3650         (JSC::Option::dump):
3651         (JSC::Option::operator==):
3652         * runtime/Options.h:
3653         * wasm/WasmPlan.cpp:
3654         (JSC::Wasm::Plan::moveToState):
3655         (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder):
3656         (JSC::Wasm::Plan::compileFunctions):
3657         * wasm/WasmPlan.h:
3658         * wasm/WasmWorklist.cpp:
3659
3660 2017-03-29  Mark Lam  <mark.lam@apple.com>
3661
3662         Remove obsolete references to HeapTimer in JavaScriptCore.order.
3663         https://bugs.webkit.org/show_bug.cgi?id=170252
3664
3665         Reviewed by Saam Barati.
3666
3667         The HeapTimer was renamed to JSRunLoopTimer back in r214504.  These HeapTimer
3668         entries are now no longer meaningful.
3669
3670         * JavaScriptCore.order:
3671
3672 2017-03-29  JF Bastien  <jfbastien@apple.com>
3673
3674         WebAssembly: add shell-only Memory mode helper
3675         https://bugs.webkit.org/show_bug.cgi?id=170227
3676
3677         Reviewed by Mark Lam.
3678
3679         * jsc.cpp:
3680         (GlobalObject::finishCreation):
3681         (functionWebAssemblyMemoryMode):
3682         * wasm/WasmMemory.h:
3683         * wasm/js/JSWebAssemblyInstance.h:
3684         * wasm/js/JSWebAssemblyMemory.h:
3685
3686 2017-03-29  Keith Miller  <keith_miller@apple.com>
3687
3688         WebAssembly: pack OpcodeOrigin to fit in a pointer
3689         https://bugs.webkit.org/show_bug.cgi?id=170244
3690
3691         Reviewed by Michael Saboff.
3692
3693         This patch makes it so we don't have to have allocate the OpcodeOrigin and can just
3694         pack all the data into the pointer B3::Origin already has.
3695
3696         * wasm/WasmB3IRGenerator.cpp:
3697         (JSC::Wasm::parseAndCompile):
3698         * wasm/WasmOpcodeOrigin.cpp:
3699         (JSC::Wasm::OpcodeOrigin::dump):
3700         * wasm/WasmOpcodeOrigin.h:
3701         (JSC::Wasm::OpcodeOrigin::OpcodeOrigin):
3702         (JSC::Wasm::OpcodeOrigin::opcode):
3703         (JSC::Wasm::OpcodeOrigin::location):
3704
3705 2017-03-29  JF Bastien  <jfbastien@apple.com>
3706
3707         WebAssembly: NFC s/goto/lambda/g
3708         https://bugs.webkit.org/show_bug.cgi?id=170242
3709
3710         Reviewed by Mark Lam.
3711
3712         Lambdas are more in-style than the goto I just used.
3713
3714         * wasm/WasmMemory.cpp:
3715         (JSC::Wasm::tryGetFastMemory):
3716
3717 2017-03-28  Saam Barati  <sbarati@apple.com>
3718
3719         AssemblyHelpers should not have a VM field
3720         https://bugs.webkit.org/show_bug.cgi?id=170207
3721
3722         Reviewed by Yusuke Suzuki.
3723
3724         APIs that need VM should take one as a parameter. When doing position
3725         independent code for Wasm, we can't tie code generation to a VM.
3726
3727         * b3/B3Compile.cpp:
3728         (JSC::B3::compile):
3729         * b3/air/testair.cpp:
3730         * b3/testb3.cpp:
3731         (JSC::B3::testEntrySwitchSimple):
3732         (JSC::B3::testEntrySwitchNoEntrySwitch):
3733         (JSC::B3::testEntrySwitchWithCommonPaths):
3734         (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
3735         (JSC::B3::testEntrySwitchLoop):
3736         * bytecode/AccessCase.cpp:
3737         (JSC::AccessCase::generateWithGuard):
3738         (JSC::AccessCase::generateImpl):
3739         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
3740         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
3741         * bytecode/InlineAccess.cpp:
3742         (JSC::InlineAccess::dumpCacheSizesAndCrash):
3743         (JSC::InlineAccess::generateSelfPropertyAccess):
3744         (JSC::InlineAccess::generateSelfPropertyReplace):
3745         (JSC::InlineAccess::generateArrayLength):
3746         (JSC::InlineAccess::rewireStubAsJump):
3747         * bytecode/InlineAccess.h:
3748         * bytecode/PolymorphicAccess.cpp:
3749         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
3750         (JSC::PolymorphicAccess::regenerate):
3751         * bytecode/PolymorphicAccess.h:
3752         (JSC::AccessGenerationState::AccessGenerationState):
3753         * dfg/DFGJITCompiler.cpp:
3754         (JSC::DFG::JITCompiler::JITCompiler):
3755         (JSC::DFG::JITCompiler::compileExceptionHandlers):
3756         (JSC::DFG::JITCompiler::link):
3757         (JSC::DFG::JITCompiler::compile):
3758         (JSC::DFG::JITCompiler::compileFunction):
3759         (JSC::DFG::JITCompiler::exceptionCheck):
3760         * dfg/DFGJITCompiler.h:
3761         (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
3762         (JSC::DFG::JITCompiler::fastExceptionCheck):
3763         (JSC::DFG::JITCompiler::vm):
3764         * dfg/DFGOSRExitCompiler.cpp:
3765         * dfg/DFGOSRExitCompiler.h:
3766         * dfg/DFGOSRExitCompiler32_64.cpp:
3767         (JSC::DFG::OSRExitCompiler::compileExit):
3768         * dfg/DFGOSRExitCompiler64.cpp:
3769         (JSC::DFG::OSRExitCompiler::compileExit):
3770         * dfg/DFGOSRExitCompilerCommon.cpp:
3771         (JSC::DFG::adjustAndJumpToTarget):
3772         * dfg/DFGOSRExitCompilerCommon.h:
3773         * dfg/DFGSpeculativeJIT.cpp:
3774         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
3775         (JSC::DFG::SpeculativeJIT::checkArray):
3776         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3777         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
3778         (JSC::DFG::SpeculativeJIT::compileMakeRope):
3779         (JSC::DFG::SpeculativeJIT::compileGetGlobalObject):
3780         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
3781         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
3782         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
3783         (JSC::DFG::SpeculativeJIT::compileSpread):
3784         (JSC::DFG::SpeculativeJIT::compileArraySlice):
3785         (JSC::DFG::SpeculativeJIT::compileNukeStructureAndSetButterfly):
3786         (JSC::DFG::SpeculativeJIT::compileNewStringObject):
3787         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
3788         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
3789         * dfg/DFGSpeculativeJIT.h:
3790         (JSC::DFG::SpeculativeJIT::emitAllocateJSObjectWithKnownSize):
3791         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
3792         (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
3793         (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
3794         * dfg/DFGSpeculativeJIT32_64.cpp:
3795         (JSC::DFG::SpeculativeJIT::emitCall):
3796         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
3797         (JSC::DFG::SpeculativeJIT::emitBranch):
3798         (JSC::DFG::SpeculativeJIT::compile):
3799         * dfg/DFGSpeculativeJIT64.cpp:
3800         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
3801         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
3802         (JSC::DFG::SpeculativeJIT::emitCall):
3803         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3804         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
3805         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3806         (JSC::DFG::SpeculativeJIT::emitBranch):
3807         (JSC::DFG::SpeculativeJIT::compile):
3808         (JSC::DFG::SpeculativeJIT::compileAllocateNewArrayWithSize):
3809         * dfg/DFGThunks.cpp:
3810         (JSC::DFG::osrEntryThunkGenerator):
3811         * ftl/FTLCompile.cpp:
3812         (JSC::FTL::compile):
3813         * ftl/FTLJITFinalizer.h:
3814         * ftl/FTLLazySlowPath.cpp:
3815         (JSC::FTL::LazySlowPath::generate):
3816         * ftl/FTLLazySlowPathCall.h:
3817         (JSC::FTL::createLazyCallGenerator):
3818         * ftl/FTLLink.cpp:
3819         (JSC::FTL::link):
3820         * ftl/FTLLowerDFGToB3.cpp:
3821         (JSC::FTL::DFG::LowerDFGToB3::lower):
3822         (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
3823         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
3824         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
3825         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
3826         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
3827         (JSC::FTL::DFG::LowerDFGToB3::compileNotifyWrite):
3828         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
3829         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
3830         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
3831         (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
3832         (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
3833         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
3834         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
3835         (JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
3836         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
3837         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
3838         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
3839         (JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
3840         * ftl/FTLOSRExitCompiler.cpp:
3841         (JSC::FTL::compileStub):
3842         * ftl/FTLSlowPathCall.h:
3843         (JSC::FTL::callOperation):
3844         * ftl/FTLState.h:
3845         (JSC::FTL::State::vm):
3846         * ftl/FTLThunks.cpp:
3847         (JSC::FTL::genericGenerationThunkGenerator):
3848         (JSC::FTL::slowPathCallThunkGenerator):
3849         * jit/AssemblyHelpers.cpp:
3850         (JSC::AssemblyHelpers::jitReleaseAssertNoException):
3851         (JSC::AssemblyHelpers::callExceptionFuzz):
3852         (JSC::AssemblyHelpers::emitJumpIfException):
3853         (JSC::AssemblyHelpers::emitExceptionCheck):
3854         (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
3855         (JSC::AssemblyHelpers::emitLoadStructure):
3856         (JSC::AssemblyHelpers::emitRandomThunk):
3857         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
3858         (JSC::AssemblyHelpers::emitConvertValueToBoolean):
3859         (JSC::AssemblyHelpers::debugCall):
3860         * jit/AssemblyHelpers.h:
3861         (JSC::AssemblyHelpers::AssemblyHelpers):
3862         (JSC::AssemblyHelpers::codeBlock):
3863         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
3864         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
3865         (JSC::AssemblyHelpers::barrierBranch):
3866         (JSC::AssemblyHelpers::barrierStoreLoadFence):
3867         (JSC::AssemblyHelpers::mutatorFence):
3868         (JSC::AssemblyHelpers::storeButterfly):
3869         (JSC::AssemblyHelpers::nukeStructureAndStoreButterfly):
3870         (JSC::AssemblyHelpers::jumpIfMutatorFenceNotNeeded):
3871         (JSC::AssemblyHelpers::emitAllocateJSObjectWithKnownSize):
3872         (JSC::AssemblyHelpers::emitAllocateJSObject):
3873         (JSC::AssemblyHelpers::emitAllocateVariableSizedCell):
3874         (JSC::AssemblyHelpers::emitAllocateVariableSizedJSObject):
3875         (JSC::AssemblyHelpers::emitAllocateDestructibleObject):
3876         (JSC::AssemblyHelpers::vm): Deleted.
3877         (JSC::AssemblyHelpers::debugCall): Deleted.
3878         * jit/CCallHelpers.cpp:
3879         (JSC::CCallHelpers::ensureShadowChickenPacket):
3880         * jit/CCallHelpers.h:
3881         (JSC::CCallHelpers::CCallHelpers):
3882         (JSC::CCallHelpers::jumpToExceptionHandler):
3883         * jit/JIT.cpp:
3884         (JSC::JIT::emitEnterOptimizationCheck):
3885         (JSC::JIT::privateCompileExceptionHandlers):
3886         * jit/JIT.h:
3887         (JSC::JIT::exceptionCheck):
3888         (JSC::JIT::exceptionCheckWithCallFrameRollback):
3889         * jit/JITMathIC.h:
3890         (JSC::JITMathIC::generateOutOfLine):
3891         * jit/JITOpcodes.cpp:
3892         (JSC::JIT::emit_op_instanceof):
3893         (JSC::JIT::emit_op_is_undefined):
3894         (JSC::JIT::emit_op_jfalse):
3895         (JSC::JIT::emit_op_jeq_null):
3896         (JSC::JIT::emit_op_jneq_null):
3897         (JSC::JIT::emit_op_jtrue):
3898         (JSC::JIT::emit_op_throw):
3899         (JSC::JIT::emit_op_catch):
3900         (JSC::JIT::emit_op_eq_null):
3901         (JSC::JIT::emit_op_neq_null):
3902         (JSC::JIT::emitSlow_op_loop_hint):
3903         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
3904         (JSC::JIT::emit_op_log_shadow_chicken_tail):
3905         * jit/JITOpcodes32_64.cpp:
3906         (JSC::JIT::privateCompileCTINativeCall):
3907         (JSC::JIT::emit_op_new_object):
3908         (JSC::JIT::emit_op_jfalse):
3909         (JSC::JIT::emit_op_jtrue):
3910         (JSC::JIT::emit_op_throw):
3911         (JSC::JIT::emit_op_catch):
3912         (JSC::JIT::emit_op_create_this):
3913         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
3914         (JSC::JIT::emit_op_log_shadow_chicken_tail):
3915         * jit/JITPropertyAccess.cpp:
3916         (JSC::JIT::emitWriteBarrier):
3917         * jit/JSInterfaceJIT.h:
3918         (JSC::JSInterfaceJIT::JSInterfaceJIT):
3919         (JSC::JSInterfaceJIT::vm):
3920         * jit/Repatch.cpp:
3921         (JSC::tryCacheGetByID):
3922         (JSC::tryCachePutByID):
3923         (JSC::linkPolymorphicCall):
3924         (JSC::resetGetByID):
3925         (JSC::resetPutByID):
3926         * jit/SetupVarargsFrame.cpp:
3927         (JSC::emitSetupVarargsFrameFastCase):
3928         * jit/SetupVarargsFrame.h:
3929         * jit/SpecializedThunkJIT.h:
3930         (JSC::SpecializedThunkJIT::loadArgumentWithSpecificClass):
3931         * jit/ThunkGenerators.cpp:
3932         (JSC::throwExceptionFromCallSlowPathGenerator):
3933         (JSC::linkCallThunkGenerator):
3934         (JSC::linkPolymorphicCallThunkGenerator):
3935         (JSC::virtualThunkFor):
3936         (JSC::nativeForGenerator):
3937      &