[Win] jsc.exe sometimes never exits.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-01-03  Per Arne Vollan  <pvollan@apple.com>
2
3         [Win] jsc.exe sometimes never exits.
4         https://bugs.webkit.org/show_bug.cgi?id=158073
5
6         Reviewed by Darin Adler.
7
8         On Windows the thread specific destructor is also called when the main thread is exiting.
9         This may lead to the main thread waiting forever for the machine thread lock when exiting,
10         if the sampling profiler thread was terminated by the system while holding the machine
11         thread lock.
12
13         * heap/MachineStackMarker.cpp:
14         (JSC::MachineThreads::removeThread):
15
16 2017-01-02  Julien Brianceau  <jbriance@cisco.com>
17
18         Remove sh4 specific code from JavaScriptCore
19         https://bugs.webkit.org/show_bug.cgi?id=166640
20
21         Reviewed by Filip Pizlo.
22
23         sh4-specific code does not compile for a while (r189884 at least).
24         As nobody seems to have interest in this architecture anymore, let's
25         remove this dead code and thus ease the burden for JSC maintainers.
26
27         * CMakeLists.txt:
28         * JavaScriptCore.xcodeproj/project.pbxproj:
29         * assembler/AbstractMacroAssembler.h:
30         (JSC::AbstractMacroAssembler::Jump::Jump):
31         (JSC::AbstractMacroAssembler::Jump::link):
32         * assembler/MacroAssembler.h:
33         * assembler/MacroAssemblerSH4.h: Removed.
34         * assembler/MaxFrameExtentForSlowPathCall.h:
35         * assembler/SH4Assembler.h: Removed.
36         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
37         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
38         * dfg/DFGSpeculativeJIT.h:
39         (JSC::DFG::SpeculativeJIT::callOperation):
40         * jit/AssemblyHelpers.h:
41         (JSC::AssemblyHelpers::debugCall):
42         * jit/CCallHelpers.h:
43         (JSC::CCallHelpers::setupArgumentsWithExecState):
44         (JSC::CCallHelpers::prepareForTailCallSlow):
45         * jit/CallFrameShuffler.cpp:
46         (JSC::CallFrameShuffler::prepareForTailCall):
47         * jit/ExecutableAllocator.h:
48         * jit/FPRInfo.h:
49         * jit/GPRInfo.h:
50         * jit/JITInlines.h:
51         (JSC::JIT::callOperation):
52         * jit/JITOpcodes32_64.cpp:
53         (JSC::JIT::privateCompileCTINativeCall):
54         * jit/JITOperations.cpp:
55         * jit/RegisterSet.cpp:
56         (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
57         (JSC::RegisterSet::dfgCalleeSaveRegisters):
58         * jit/ThunkGenerators.cpp:
59         (JSC::nativeForGenerator):
60         * llint/LLIntData.cpp:
61         (JSC::LLInt::Data::performAssertions):
62         * llint/LLIntOfflineAsmConfig.h:
63         * llint/LowLevelInterpreter.asm:
64         * llint/LowLevelInterpreter32_64.asm:
65         * offlineasm/backends.rb:
66         * offlineasm/instructions.rb:
67         * offlineasm/sh4.rb: Removed.
68         * yarr/YarrJIT.cpp:
69         (JSC::Yarr::YarrGenerator::generateEnter):
70         (JSC::Yarr::YarrGenerator::generateReturn):
71
72 2017-01-02  JF Bastien  <jfbastien@apple.com>
73
74         WebAssembly: handle and optimize wasm export → wasm import calls
75         https://bugs.webkit.org/show_bug.cgi?id=165282
76
77         Reviewed by Saam Barati.
78
79           - Add a new JSType for WebAssemblyFunction, and use it when creating its
80             structure. This will is used to quickly detect from wasm whether the import
81             call is to another wasm module, or whether it's to JS.
82           - Generate two stubs from the import stub generator: one for wasm->JS and one
83             for wasm -> wasm. This is done at Module time. Which is called will only be
84             known at Instance time, once we've received the import object. We want to
85             avoid codegen at Instance time, so having both around is great.
86           - Restore the WebAssembly global state (VM top Instance, and pinned registers)
87             after call / call_indirect, and in the JS->wasm entry stub.
88           - Pinned registers are now a global thing, not per-Memory, because the wasm ->
89             wasm stubs are generated at Module time where we don't really have enough
90             information to do the right thing (doing so would generate too much code).
91
92         * CMakeLists.txt:
93         * JavaScriptCore.xcodeproj/project.pbxproj:
94         * runtime/JSType.h: add WebAssemblyFunctionType as a JSType
95         * wasm/WasmB3IRGenerator.cpp: significantly rework how calls which
96         could be external work, and how we save / restore global state:
97         VM's top Instance, and pinned registers
98         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
99         (JSC::Wasm::getMemoryBaseAndSize):
100         (JSC::Wasm::restoreWebAssemblyGlobalState):
101         (JSC::Wasm::createJSToWasmWrapper):
102         (JSC::Wasm::parseAndCompile):
103         * wasm/WasmB3IRGenerator.h:
104         * wasm/WasmBinding.cpp:
105         (JSC::Wasm::materializeImportJSCell):
106         (JSC::Wasm::wasmToJS):
107         (JSC::Wasm::wasmToWasm): the main goal of this patch was adding this function
108         (JSC::Wasm::exitStubGenerator):
109         * wasm/WasmBinding.h:
110         * wasm/WasmFormat.h: Get rid of much of the function index space:
111         we already have all of its information elsewhere, and as-is it
112         provides no extra efficiency.
113         (JSC::Wasm::ModuleInformation::functionIndexSpaceSize):
114         (JSC::Wasm::ModuleInformation::isImportedFunctionFromFunctionIndexSpace):
115         (JSC::Wasm::ModuleInformation::signatureIndexFromFunctionIndexSpace):
116         * wasm/WasmFunctionParser.h:
117         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
118         * wasm/WasmMemory.cpp: Add some logging.
119         (JSC::Wasm::Memory::dump): this was nice when debugging
120         (JSC::Wasm::Memory::makeString):
121         (JSC::Wasm::Memory::Memory):
122         (JSC::Wasm::Memory::~Memory):
123         (JSC::Wasm::Memory::grow):
124         * wasm/WasmMemory.h: don't use extra indirection, it wasn't
125         needed. Reorder some of the fields which are looked up at runtime
126         so they're more cache-friendly.
127         (JSC::Wasm::Memory::Memory):
128         (JSC::Wasm::Memory::mode):
129         (JSC::Wasm::Memory::offsetOfSize):
130         * wasm/WasmMemoryInformation.cpp: Pinned registers are now a
131         global thing for all of JSC, not a per-Memory thing
132         anymore. wasm->wasm calls are more complex otherwise: they have to
133         figure out how to bridge between the caller and callee's
134         special-snowflake pinning.
135         (JSC::Wasm::PinnedRegisterInfo::get):
136         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
137         (JSC::Wasm::MemoryInformation::MemoryInformation):
138         * wasm/WasmMemoryInformation.h:
139         * wasm/WasmModuleParser.cpp:
140         * wasm/WasmModuleParser.h:
141         * wasm/WasmPageCount.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
142         (JSC::Wasm::PageCount::dump): nice for debugging
143         * wasm/WasmPageCount.h:
144         * wasm/WasmPlan.cpp:
145         (JSC::Wasm::Plan::parseAndValidateModule):
146         (JSC::Wasm::Plan::run):
147         * wasm/WasmPlan.h:
148         (JSC::Wasm::Plan::takeWasmExitStubs):
149         * wasm/WasmSignature.cpp:
150         (JSC::Wasm::Signature::toString):
151         (JSC::Wasm::Signature::dump):
152         * wasm/WasmSignature.h:
153         * wasm/WasmValidate.cpp:
154         (JSC::Wasm::validateFunction):
155         * wasm/WasmValidate.h:
156         * wasm/js/JSWebAssemblyInstance.h:
157         (JSC::JSWebAssemblyInstance::offsetOfTable):
158         (JSC::JSWebAssemblyInstance::offsetOfImportFunctions):
159         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
160         * wasm/js/JSWebAssemblyMemory.cpp:
161         (JSC::JSWebAssemblyMemory::create):
162         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
163         (JSC::JSWebAssemblyMemory::buffer):
164         (JSC::JSWebAssemblyMemory::grow):
165         * wasm/js/JSWebAssemblyMemory.h:
166         (JSC::JSWebAssemblyMemory::memory):
167         (JSC::JSWebAssemblyMemory::offsetOfMemory):
168         (JSC::JSWebAssemblyMemory::offsetOfSize):
169         * wasm/js/JSWebAssemblyModule.cpp:
170         (JSC::JSWebAssemblyModule::create):
171         (JSC::JSWebAssemblyModule::JSWebAssemblyModule):
172         * wasm/js/JSWebAssemblyModule.h:
173         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace):
174         (JSC::JSWebAssemblyModule::functionImportCount):
175         * wasm/js/WebAssemblyFunction.cpp:
176         (JSC::callWebAssemblyFunction):
177         (JSC::WebAssemblyFunction::create):
178         (JSC::WebAssemblyFunction::createStructure):
179         (JSC::WebAssemblyFunction::WebAssemblyFunction):
180         (JSC::WebAssemblyFunction::finishCreation):
181         * wasm/js/WebAssemblyFunction.h:
182         (JSC::WebAssemblyFunction::wasmEntrypoint):
183         (JSC::WebAssemblyFunction::offsetOfInstance):
184         (JSC::WebAssemblyFunction::offsetOfWasmEntryPointCode):
185         * wasm/js/WebAssemblyInstanceConstructor.cpp:
186         (JSC::constructJSWebAssemblyInstance): always start with a dummy
187         memory, so wasm->wasm calls don't need to null-check
188         * wasm/js/WebAssemblyMemoryConstructor.cpp:
189         (JSC::constructJSWebAssemblyMemory):
190         * wasm/js/WebAssemblyModuleConstructor.cpp:
191         (JSC::WebAssemblyModuleConstructor::createModule):
192         * wasm/js/WebAssemblyModuleRecord.cpp:
193         (JSC::WebAssemblyModuleRecord::link):
194         (JSC::WebAssemblyModuleRecord::evaluate):
195         * wasm/js/WebAssemblyModuleRecord.h:
196
197 2017-01-02  Saam Barati  <sbarati@apple.com>
198
199         WebAssembly: Some loads don't take into account the offset
200         https://bugs.webkit.org/show_bug.cgi?id=166616
201         <rdar://problem/29841541>
202
203         Reviewed by Keith Miller.
204
205         * wasm/WasmB3IRGenerator.cpp:
206         (JSC::Wasm::B3IRGenerator::emitLoadOp):
207
208 2017-01-01  Jeff Miller  <jeffm@apple.com>
209
210         Update user-visible copyright strings to include 2017
211         https://bugs.webkit.org/show_bug.cgi?id=166278
212
213         Reviewed by Dan Bernstein.
214
215         * Info.plist:
216
217 2016-12-28  Saam Barati  <sbarati@apple.com>
218
219         WebAssembly: Don't allow duplicate export names
220         https://bugs.webkit.org/show_bug.cgi?id=166490
221         <rdar://problem/29815000>
222
223         Reviewed by Keith Miller.
224
225         * wasm/WasmModuleParser.cpp:
226
227 2016-12-28  Saam Barati  <sbarati@apple.com>
228
229         Unreviewed. Fix jsc.cpp build error.
230
231         * jsc.cpp:
232         (functionTestWasmModuleFunctions):
233
234 2016-12-28  Saam Barati  <sbarati@apple.com>
235
236         WebAssembly: Implement grow_memory and current_memory
237         https://bugs.webkit.org/show_bug.cgi?id=166448
238         <rdar://problem/29803676>
239
240         Reviewed by Keith Miller.
241
242         This patch implements grow_memory, current_memory, and WebAssembly.prototype.grow.
243         See relevant spec texts here:
244         
245         https://github.com/WebAssembly/design/blob/master/Semantics.md#linear-memory-accesses
246         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymemoryprototypegrow
247         
248         I also fix a couple miscellaneous bugs:
249         
250         1. Data section now understands full init_exprs. 
251         2. parseVarUint1 no longer has a bug where we allow values larger than 1 if
252         their bottom 8 bits are zero.
253         
254         Since the JS API can now grow memory, we need to make calling an import
255         and call_indirect refresh the base memory register and the size registers.
256
257         * jsc.cpp:
258         (functionTestWasmModuleFunctions):
259         * runtime/Options.h:
260         * runtime/VM.h:
261         * wasm/WasmB3IRGenerator.cpp:
262         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
263         (JSC::Wasm::reloadPinnedRegisters):
264         (JSC::Wasm::B3IRGenerator::emitReloadPinnedRegisters):
265         (JSC::Wasm::createJSToWasmWrapper):
266         (JSC::Wasm::parseAndCompile):
267         * wasm/WasmFormat.cpp:
268         (JSC::Wasm::Segment::create):
269         * wasm/WasmFormat.h:
270         (JSC::Wasm::I32InitExpr::I32InitExpr):
271         (JSC::Wasm::I32InitExpr::globalImport):
272         (JSC::Wasm::I32InitExpr::constValue):
273         (JSC::Wasm::I32InitExpr::isConst):
274         (JSC::Wasm::I32InitExpr::isGlobalImport):
275         (JSC::Wasm::I32InitExpr::globalImportIndex):
276         (JSC::Wasm::Segment::byte):
277         (JSC::Wasm::ModuleInformation::importFunctionCount):
278         (JSC::Wasm::ModuleInformation::hasMemory):
279         * wasm/WasmFunctionParser.h:
280         * wasm/WasmMemory.cpp:
281         (JSC::Wasm::Memory::Memory):
282         (JSC::Wasm::Memory::grow):
283         * wasm/WasmMemory.h:
284         (JSC::Wasm::Memory::size):
285         (JSC::Wasm::Memory::sizeInPages):
286         (JSC::Wasm::Memory::offsetOfMemory):
287         (JSC::Wasm::Memory::isValid): Deleted.
288         (JSC::Wasm::Memory::grow): Deleted.
289         * wasm/WasmModuleParser.cpp:
290         (JSC::Wasm::makeI32InitExpr):
291         * wasm/WasmModuleParser.h:
292         * wasm/WasmPageCount.h:
293         (JSC::Wasm::PageCount::bytes):
294         (JSC::Wasm::PageCount::pageCount):
295         (JSC::Wasm::PageCount::fromBytes):
296         (JSC::Wasm::PageCount::operator+):
297         * wasm/WasmParser.h:
298         (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
299         * wasm/WasmValidate.cpp:
300         * wasm/js/JSWebAssemblyInstance.h:
301         (JSC::JSWebAssemblyInstance::offsetOfMemory):
302         * wasm/js/JSWebAssemblyMemory.cpp:
303         (JSC::JSWebAssemblyMemory::~JSWebAssemblyMemory):
304         (JSC::JSWebAssemblyMemory::grow):
305         * wasm/js/JSWebAssemblyMemory.h:
306         (JSC::JSWebAssemblyMemory::offsetOfMemory):
307         * wasm/js/JSWebAssemblyModule.h:
308         (JSC::JSWebAssemblyModule::functionImportCount):
309         (JSC::JSWebAssemblyModule::jsEntrypointCalleeFromFunctionIndexSpace):
310         (JSC::JSWebAssemblyModule::wasmEntrypointCalleeFromFunctionIndexSpace):
311         (JSC::JSWebAssemblyModule::importCount): Deleted.
312         * wasm/js/WebAssemblyFunction.cpp:
313         (JSC::callWebAssemblyFunction):
314         * wasm/js/WebAssemblyInstanceConstructor.cpp:
315         (JSC::constructJSWebAssemblyInstance):
316         * wasm/js/WebAssemblyMemoryConstructor.cpp:
317         (JSC::constructJSWebAssemblyMemory):
318         * wasm/js/WebAssemblyMemoryPrototype.cpp:
319         (JSC::getMemory):
320         (JSC::webAssemblyMemoryProtoFuncBuffer):
321         (JSC::webAssemblyMemoryProtoFuncGrow):
322         * wasm/js/WebAssemblyModuleRecord.cpp:
323         (JSC::WebAssemblyModuleRecord::link):
324         (JSC::dataSegmentFail):
325         (JSC::WebAssemblyModuleRecord::evaluate):
326         * wasm/wasm.json:
327
328 2016-12-26  Yusuke Suzuki  <utatane.tea@gmail.com>
329
330         Use variadic templates in JSC Parser to clean up
331         https://bugs.webkit.org/show_bug.cgi?id=166482
332
333         Reviewed by Saam Barati.
334
335         * parser/Parser.cpp:
336         (JSC::Parser<LexerType>::logError):
337         * parser/Parser.h:
338
339 2016-12-25  Yusuke Suzuki  <utatane.tea@gmail.com>
340
341         Propagate the source origin as much as possible
342         https://bugs.webkit.org/show_bug.cgi?id=166348
343
344         Reviewed by Darin Adler.
345
346         This patch introduces CallFrame::callerSourceOrigin, SourceOrigin class
347         and SourceProvider::m_sourceOrigin. CallFrame::callerSourceOrigin returns
348         an appropriate SourceOrigin if possible. If we cannot find the appropriate
349         one, we just return null SourceOrigin.
350
351         This paves the way for implementing the module dynamic-import[1].
352         When the import operator is evaluated, it will resolve the module
353         specifier with this propagated source origin of the caller function.
354
355         To support import operator inside the dynamic code generation
356         functions (like `eval`, `new Function`, indirect call to `eval`),
357         we need to propagate the caller's source origin to the generated
358         source code.
359
360         We do not use sourceURL for that purpose. This is because we
361         would like to keep sourceURL for `eval` / `new Function` null.
362         This sourceURL will be used for the stack dump for errors with line/column
363         numbers. Dumping the caller's sourceURL with line/column numbers are
364         meaningless. So we would like to keep it null while we would like
365         to propagate SourceOrigin for dynamic imports.
366
367         [1]: https://github.com/tc39/proposal-dynamic-import
368
369         * API/JSBase.cpp:
370         (JSEvaluateScript):
371         (JSCheckScriptSyntax):
372         * API/JSObjectRef.cpp:
373         (JSObjectMakeFunction):
374         * API/JSScriptRef.cpp:
375         (OpaqueJSScript::create):
376         (OpaqueJSScript::vm):
377         (OpaqueJSScript::OpaqueJSScript):
378         (parseScript):
379         * JavaScriptCore.xcodeproj/project.pbxproj:
380         * Scripts/builtins/builtins_templates.py:
381         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
382         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
383         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
384         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
385         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
386         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
387         * builtins/BuiltinExecutables.cpp:
388         (JSC::BuiltinExecutables::BuiltinExecutables):
389         (JSC::BuiltinExecutables::createDefaultConstructor):
390         * debugger/DebuggerCallFrame.cpp:
391         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
392         * inspector/InjectedScriptManager.cpp:
393         (Inspector::InjectedScriptManager::createInjectedScript):
394         * inspector/JSInjectedScriptHost.cpp:
395         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
396         * inspector/agents/InspectorRuntimeAgent.cpp:
397         (Inspector::InspectorRuntimeAgent::parse):
398         * interpreter/CallFrame.cpp:
399         (JSC::CallFrame::callerSourceOrigin):
400         * interpreter/CallFrame.h:
401         * interpreter/Interpreter.cpp:
402         (JSC::eval):
403         * jsc.cpp:
404         (jscSource):
405         (GlobalObject::finishCreation):
406         (extractDirectoryName):
407         (currentWorkingDirectory):
408         (GlobalObject::moduleLoaderResolve):
409         (functionRunString):
410         (functionLoadString):
411         (functionCallerSourceOrigin):
412         (functionCreateBuiltin):
413         (functionCheckModuleSyntax):
414         (runInteractive):
415         * parser/SourceCode.h:
416         (JSC::makeSource):
417         * parser/SourceProvider.cpp:
418         (JSC::SourceProvider::SourceProvider):
419         * parser/SourceProvider.h:
420         (JSC::SourceProvider::sourceOrigin):
421         (JSC::StringSourceProvider::create):
422         (JSC::StringSourceProvider::StringSourceProvider):
423         (JSC::WebAssemblySourceProvider::create):
424         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
425         * runtime/FunctionConstructor.cpp:
426         (JSC::constructFunction):
427         (JSC::constructFunctionSkippingEvalEnabledCheck):
428         * runtime/FunctionConstructor.h:
429         * runtime/JSGlobalObjectFunctions.cpp:
430         (JSC::globalFuncEval):
431         * runtime/ModuleLoaderPrototype.cpp:
432         (JSC::moduleLoaderPrototypeParseModule):
433         * runtime/ScriptExecutable.h:
434         (JSC::ScriptExecutable::sourceOrigin):
435         * runtime/SourceOrigin.h: Added.
436         (JSC::SourceOrigin::SourceOrigin):
437         (JSC::SourceOrigin::string):
438         (JSC::SourceOrigin::isNull):
439         * tools/FunctionOverrides.cpp:
440         (JSC::initializeOverrideInfo):
441
442 2016-12-24  Caio Lima  <ticaiolima@gmail.com>
443
444         [test262] Fixing mapped arguments object property test case
445         https://bugs.webkit.org/show_bug.cgi?id=159398
446
447         Reviewed by Saam Barati.
448
449         This patch changes GenericArguments' override mechanism to
450         implement corret behavior on ECMAScript test262 suite test cases of
451         mapped arguments object with non-configurable and non-writable
452         property. Also it is ensuring that arguments[i]
453         cannot be deleted when argument "i" is {configurable: false}.
454         
455         The previous implementation is against to the specification for 2 reasons:
456
457         1. Every argument in arguments object are {writable: true} by default
458            (http://www.ecma-international.org/ecma-262/7.0/index.html#sec-createunmappedargumentsobject).
459            It means that we have to stop mapping a defined property index
460            if the new property descriptor contains writable (i.e writable is
461            present) and its value is false (also check
462            https://tc39.github.io/ecma262/#sec-arguments-exotic-objects-defineownproperty-p-desc).
463            Previous implementation considers {writable: false} if writable is
464            not present.
465
466         2. When a property is overriden, "delete" operation is always returning true. However
467            delete operations should follow the specification.
468
469         We created an auxilary boolean array named m_modifiedArgumentsDescriptor
470         to store which arguments[i] descriptor was changed from its default
471         property descriptor. This modification was necessary because m_overrides
472         was responsible to keep this information at the same time
473         of keeping information about arguments mapping. The problem of this apporach was
474         that we needed to call overridesArgument(i) as soon as the ith argument's property
475         descriptor was changed and it stops the argument's mapping as sideffect, producing
476         wrong behavior.
477         To keep tracking arguments mapping status, we renamed DirectArguments::m_overrides to
478         DirectArguments::m_mappedArguments and now we it is responsible to manage if an
479         argument[i] is mapped or not.
480         With these 2 structures, now it is possible to an argument[i] have its property 
481         descriptor modified and don't stop the mapping as soon as it happens. One example
482         of that wrong behavior can be found on arguments-bizarre-behaviour-disable-enumerability
483         test case, that now is fixed by this new mechanism.
484
485         * bytecode/PolymorphicAccess.cpp:
486         (JSC::AccessCase::generateWithGuard):
487         * dfg/DFGSpeculativeJIT.cpp:
488         (JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
489         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
490         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
491         * ftl/FTLAbstractHeapRepository.h:
492         * ftl/FTLLowerDFGToB3.cpp:
493         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
494         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
495         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
496         * jit/JITOperations.cpp:
497         (JSC::canAccessArgumentIndexQuickly):
498         * jit/JITPropertyAccess.cpp:
499         (JSC::JIT::emitDirectArgumentsGetByVal):
500         * runtime/DirectArguments.cpp:
501         (JSC::DirectArguments::estimatedSize):
502         (JSC::DirectArguments::visitChildren):
503         (JSC::DirectArguments::overrideThings):
504         (JSC::DirectArguments::overrideThingsIfNecessary):
505         (JSC::DirectArguments::unmapArgument):
506         (JSC::DirectArguments::copyToArguments):
507         (JSC::DirectArguments::overridesSize):
508         (JSC::DirectArguments::overrideArgument): Deleted.
509         * runtime/DirectArguments.h:
510         (JSC::DirectArguments::length):
511         (JSC::DirectArguments::isMappedArgument):
512         (JSC::DirectArguments::isMappedArgumentInDFG):
513         (JSC::DirectArguments::getIndexQuickly):
514         (JSC::DirectArguments::setIndexQuickly):
515         (JSC::DirectArguments::overrodeThings):
516         (JSC::DirectArguments::initModifiedArgumentsDescriptorIfNecessary):
517         (JSC::DirectArguments::setModifiedArgumentDescriptor):
518         (JSC::DirectArguments::isModifiedArgumentDescriptor):
519         (JSC::DirectArguments::offsetOfMappedArguments):
520         (JSC::DirectArguments::offsetOfModifiedArgumentsDescriptor):
521         (JSC::DirectArguments::canAccessIndexQuickly): Deleted.
522         (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
523         (JSC::DirectArguments::offsetOfOverrides): Deleted.
524         * runtime/GenericArguments.h:
525         * runtime/GenericArgumentsInlines.h:
526         (JSC::GenericArguments<Type>::visitChildren):
527         (JSC::GenericArguments<Type>::getOwnPropertySlot):
528         (JSC::GenericArguments<Type>::getOwnPropertySlotByIndex):
529         (JSC::GenericArguments<Type>::getOwnPropertyNames):
530         (JSC::GenericArguments<Type>::put):
531         (JSC::GenericArguments<Type>::putByIndex):
532         (JSC::GenericArguments<Type>::deleteProperty):
533         (JSC::GenericArguments<Type>::deletePropertyByIndex):
534         (JSC::GenericArguments<Type>::defineOwnProperty):
535         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
536         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptorIfNecessary):
537         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
538         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
539         (JSC::GenericArguments<Type>::copyToArguments):
540         * runtime/ScopedArguments.cpp:
541         (JSC::ScopedArguments::visitChildren):
542         (JSC::ScopedArguments::unmapArgument):
543         (JSC::ScopedArguments::overrideArgument): Deleted.
544         * runtime/ScopedArguments.h:
545         (JSC::ScopedArguments::isMappedArgument):
546         (JSC::ScopedArguments::isMappedArgumentInDFG):
547         (JSC::ScopedArguments::getIndexQuickly):
548         (JSC::ScopedArguments::setIndexQuickly):
549         (JSC::ScopedArguments::initModifiedArgumentsDescriptorIfNecessary):
550         (JSC::ScopedArguments::setModifiedArgumentDescriptor):
551         (JSC::ScopedArguments::isModifiedArgumentDescriptor):
552         (JSC::ScopedArguments::canAccessIndexQuickly): Deleted.
553         (JSC::ScopedArguments::canAccessArgumentIndexQuicklyInDFG): Deleted.
554
555 2016-12-23  Mark Lam  <mark.lam@apple.com>
556
557         Using Option::breakOnThrow() shouldn't crash while printing a null CodeBlock.
558         https://bugs.webkit.org/show_bug.cgi?id=166466
559
560         Reviewed by Keith Miller.
561
562         * runtime/VM.cpp:
563         (JSC::VM::throwException):
564
565 2016-12-23  Mark Lam  <mark.lam@apple.com>
566
567         Enhance LLInt tracing to dump the codeBlock signature instead of just a pointer where appropriate.
568         https://bugs.webkit.org/show_bug.cgi?id=166465
569
570         Reviewed by Keith Miller.
571
572         * llint/LLIntSlowPaths.cpp:
573         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
574         (JSC::LLInt::traceFunctionPrologue):
575
576 2016-12-23  Keith Miller  <keith_miller@apple.com>
577
578         WebAssembly: trap on bad division.
579         https://bugs.webkit.org/show_bug.cgi?id=164786
580
581         Reviewed by Mark Lam.
582
583         This patch adds traps for division / modulo by zero and for
584         division by int_min / -1.
585
586         * wasm/WasmB3IRGenerator.cpp:
587         (JSC::Wasm::B3IRGenerator::emitChecksForModOrDiv):
588         * wasm/WasmExceptionType.h:
589         * wasm/WasmPlan.cpp:
590         (JSC::Wasm::Plan::run):
591         * wasm/wasm.json:
592
593 2016-12-23  Mark Lam  <mark.lam@apple.com>
594
595         Fix broken LLINT_SLOW_PATH_TRACING build.
596         https://bugs.webkit.org/show_bug.cgi?id=166463
597
598         Reviewed by Keith Miller.
599
600         * llint/LLIntExceptions.cpp:
601         (JSC::LLInt::returnToThrow):
602         (JSC::LLInt::callToThrow):
603         * runtime/CommonSlowPathsExceptions.cpp:
604         (JSC::CommonSlowPaths::interpreterThrowInCaller):
605
606 2016-12-22  Keith Miller  <keith_miller@apple.com>
607
608         WebAssembly: Make spec-tests/f32.wast.js and spec-tests/f64.wast.js pass
609         https://bugs.webkit.org/show_bug.cgi?id=166447
610
611         Reviewed by Saam Barati.
612
613         We needed to treat -0.0 < 0.0 for floating point min/max. For min,
614         the algorithm works because if a == b then a and b are not NaNs so
615         either they are the same or they are some zero. When we or a and b
616         either we get the same number back or we get -0.0. Similarly for
617         max we use an and and the sign bit gets dropped if one is 0.0 and
618         the other is -0.0, otherwise, we get the same number back.
619
620         * wasm/wasm.json:
621
622 2016-12-22  Saam Barati  <sbarati@apple.com>
623
624         WebAssembly: Make calling Wasm functions that returns or takes an i64 as a parameter an early exception
625         https://bugs.webkit.org/show_bug.cgi?id=166437
626         <rdar://problem/29793949>
627
628         Reviewed by Keith Miller.
629
630         This patch makes it so that we throw an exception before we do
631         anything else if we call a wasm function that either takes an
632         i64 as an argument or returns an i64.
633
634         * wasm/js/WebAssemblyFunction.cpp:
635         (JSC::callWebAssemblyFunction):
636         (JSC::WebAssemblyFunction::WebAssemblyFunction):
637         (JSC::WebAssemblyFunction::call): Deleted.
638         * wasm/js/WebAssemblyFunction.h:
639         (JSC::WebAssemblyFunction::signatureIndex):
640         (JSC::WebAssemblyFunction::jsEntrypoint):
641
642 2016-12-22  Keith Miller  <keith_miller@apple.com>
643
644         Add BitOr for floating points to B3
645         https://bugs.webkit.org/show_bug.cgi?id=166446
646
647         Reviewed by Saam Barati.
648
649         This patch does some slight refactoring to the ARM assembler,
650         which groups all the vector floating point instructions together.
651
652         * assembler/ARM64Assembler.h:
653         (JSC::ARM64Assembler::vand):
654         (JSC::ARM64Assembler::vorr):
655         (JSC::ARM64Assembler::vectorDataProcessingLogical):
656         (JSC::ARM64Assembler::vectorDataProcessing2Source): Deleted.
657         * assembler/MacroAssemblerARM64.h:
658         (JSC::MacroAssemblerARM64::orDouble):
659         (JSC::MacroAssemblerARM64::orFloat):
660         * assembler/MacroAssemblerX86Common.h:
661         (JSC::MacroAssemblerX86Common::orDouble):
662         (JSC::MacroAssemblerX86Common::orFloat):
663         * assembler/X86Assembler.h:
664         (JSC::X86Assembler::orps_rr):
665         * b3/B3ConstDoubleValue.cpp:
666         (JSC::B3::ConstDoubleValue::bitOrConstant):
667         (JSC::B3::ConstDoubleValue::bitXorConstant):
668         * b3/B3ConstDoubleValue.h:
669         * b3/B3ConstFloatValue.cpp:
670         (JSC::B3::ConstFloatValue::bitOrConstant):
671         (JSC::B3::ConstFloatValue::bitXorConstant):
672         * b3/B3ConstFloatValue.h:
673         * b3/B3LowerToAir.cpp:
674         (JSC::B3::Air::LowerToAir::lower):
675         * b3/B3Validate.cpp:
676         * b3/air/AirInstInlines.h:
677         (JSC::B3::Air::Inst::shouldTryAliasingDef):
678         * b3/air/AirOpcode.opcodes:
679         * b3/testb3.cpp:
680         (JSC::B3::bitOrDouble):
681         (JSC::B3::testBitOrArgDouble):
682         (JSC::B3::testBitOrArgsDouble):
683         (JSC::B3::testBitOrArgImmDouble):
684         (JSC::B3::testBitOrImmsDouble):
685         (JSC::B3::bitOrFloat):
686         (JSC::B3::testBitOrArgFloat):
687         (JSC::B3::testBitOrArgsFloat):
688         (JSC::B3::testBitOrArgImmFloat):
689         (JSC::B3::testBitOrImmsFloat):
690         (JSC::B3::testBitOrArgsFloatWithUselessDoubleConversion):
691         (JSC::B3::run):
692
693 2016-12-22  Mark Lam  <mark.lam@apple.com>
694
695         BytecodeGenerator::m_finallyDepth should be unsigned.
696         https://bugs.webkit.org/show_bug.cgi?id=166438
697
698         Reviewed by Saam Barati.
699
700         Also removed FinallyContext::m_finallyDepth because it is not used.
701
702         * bytecompiler/BytecodeGenerator.cpp:
703         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
704         (JSC::BytecodeGenerator::labelScopeDepth):
705         * bytecompiler/BytecodeGenerator.h:
706         (JSC::FinallyContext::FinallyContext):
707         (JSC::FinallyContext::finallyLabel):
708         (JSC::FinallyContext::depth): Deleted.
709
710 2016-12-22  Mark Lam  <mark.lam@apple.com>
711
712         De-duplicate finally blocks.
713         https://bugs.webkit.org/show_bug.cgi?id=160168
714
715         Reviewed by Saam Barati.
716
717         JS execution can arrive at a finally block when there are abrupt completions from
718         its try or catch block.  The abrupt completion types include Break,
719         Continue, Return, and Throw.  The non-abrupt completion type is called Normal
720         (i.e. the case of a try block falling through to the finally block).
721
722         Previously, we enable each of these paths for abrupt completion (except for Throw)
723         to run the finally block code by duplicating the finally block code at each of
724         the sites that trigger those completions.  This patch fixes the implementation so
725         that each of these abrupt completions will set a completionTypeRegister (plus a
726         completionValueRegister for CompletionType::Return) and then jump to the
727         relevant finally blocks, and continue to thread through subsequent outer finally
728         blocks until execution reaches the outermost finally block that the completion
729         type dictates.  We no longer duplicate the finally block code.
730
731         The implementation details:
732         1. We allocate a pair of registers (completionTypeRegister and completionValueRegister)
733            just before entering the outermost try-catch-finally scope.
734
735            On allocating the registers, we initialize the completionTypeRegister to
736            CompletionType::Normal, and set the completionValueRegister to the empty
737            JSValue.
738
739         2. The completionTypeRegister will hold a CompletionType value.  This is how we
740            encode the CompletionType value to be set:
741
742            a. For Normal, Return, and Throw completion types: 
743               - The completionTypeRegister is set to CompletionType::Normal,
744                 CompletionType::Return, and CompletionType::Throw respectively.
745
746            b. For Break and Continue completion types:
747               - The completionTypeRegister is set to a unique jumpID where the jumpID is
748                 computed as:
749
750                 jumpID = CompletionType::NumberOfTypes + bytecodeOffset
751
752                 The bytecodeOffset used here is the bytecodeOffset of the break or continue
753                 statement that triggered this completion.
754
755         3. Each finally block will have 2 entries:
756            a. the catch entry.
757            b. the normal entry.
758
759            The catch entry is recorded in the codeBlock's exception handler table,
760            and can only be jumped to by the VM's exception handling mechanism.
761
762            The normal entry is recorded in a FinallyContext (at bytecode generation time
763            only) and is jumped to when we want enter the finally block due any of the
764            other CompletionTypes.
765
766         4. How each completion type works?
767
768            CompletionType::Normal
769            ======================
770            We normally encounter this when falling through from a try or catch block to
771            the finally block.  
772           
773            For the try block case, since completionTypeRegister is set to Normal by default,
774            there's nothing more that needs to be done.
775
776            For the catch block case, since we entered the catch block with an exception,
777            completionTypeRegister may be set to Throw.  We'll need to set it to Normal
778            before jumping to the finally block's normal entry.
779
780            CompletionType::Break
781            =====================
782            When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
783            that we need to service before jumping to the breakTarget.  If we don't, then
784            emit op_jump to the breakTarget as usual.  Otherwise:
785
786            a. we'll register a jumpID and the breakTarget with the FinallyContext for the
787               outermost finally block that we're supposed to run through.
788            b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
789               from the innermost to the one for that outermost finally block.
790            c. emit bytecode to set the completionTypeRegister to the jumpID.
791            d. emit bytecode to jump to the normal entry of the innermost finally block.
792
793            Each finally block will take care of cascading to the next outer finally block
794            as needed (see (5) below).
795
796            CompletionType::Continue
797            ========================
798            Since continues and breaks work the same way (i.e. with a jump), we handle this
799            exactly the same way as CompletionType::Break, except that we use the
800            continueTarget instead of the breakTarget.
801
802            CompletionType::Return
803            ======================
804            When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
805            at all on the m_controlFlowScopeStack.  If we don't, then emit op_ret as usual.
806            Otherwise:
807
808            a. emit bytecode to set the completionTypeRegister to CompletionType::Return.
809            b. emit bytecode to move the return value into the completionValueRegister.
810            c. emit bytecode to jump to the normal entry of the innermost finally block.
811
812            Each finally block will take care of cascading to the next outer finally block
813            as needed (see (5) below).
814
815            CompletionType::Throw
816            ======================
817            At the catch entry a finally block, we:
818            1. emit an op_catch that stores the caught Exception object in the
819               completionValueRegister.
820            2. emit bytecode to set the completionTypeRegister to CompletionType::Throw.
821            3. Fall through or jump to the finally block's normal entry.
822
823         5. What happens in each finally block?
824            ==================================
825            For details on the finally block's catch entry, see "CompletionType::Throw" in
826            (4) above.
827
828            The finally block's normal entry will:
829            1. restore the scope of the finally block.
830            2. save the completionTypeRegister in a savedCompletionTypeRegister.
831            3. proceed to execute the body of the finally block.
832
833            At the end of the finally block, we will emit bytecode check the
834            savedCompletionTypeRegister for each completion type see emitFinallyCompletion())
835            in the following order:
836           
837            a. Check for CompletionType::Normal
838               ================================
839               If savedCompletionTypeRegister is CompletionType::Normal, jump to the
840               designated normalCompletion label.  We only need this check this finally
841               block also needs to check for Break, Continue, or Return.  If not, the
842               completion type check for CompletionType::Throw below will make this check
843               redundant.
844
845            b. Check for CompletionType::Break and Continue
846               ============================================
847               If the FinallyContext for this block has registered FinallyJumps, we'll
848               check the jumpIDs against the savedCompletionTypeRegister.  If the jumpID
849               matches, jump to the corresponding jumpTarget.
850
851               If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
852               greater than the number of registered FinallyJumps, then this means that
853               we have a Break or Continue that needs to be handled by an outer finally
854               block.  In that case, jump to the next outer finally block's normal entry.
855              
856            c. Check for CompletionType::Return
857               ================================
858               If this finally block is not the outermost and the savedCompletionTypeRegister
859               is set to CompletionType::Return, then jump to the next outer finally
860               block's normal entry.
861
862               Otherwise, if this finally block is the outermost and the savedCompletionTypeRegister
863               is set to CompletionType::Return, then execute op_ret and return the value
864               in the completionValueRegister.
865
866            d. CompletionType::Throw
867               =====================
868               If savedCompletionTypeRegister is CompletionType::Throw, then just re-throw the
869               Exception object in the completionValueRegister.
870
871            Detail 1: that we check the savedCompletionTypeRegister (and not the
872            completionTypeRegister).  This is because the finally block may itself contain
873            a try-finally, and this inner try-finally may have trashed the completionTypeRegister.
874            Here's an example:
875
876                try {
877                    return "r1"; // Sets completionTypeRegister to CompletionType::Return;
878                } finally {
879                    // completionTypeRegister is CompletionType::Return here.
880
881                    try {
882                        ... // do stuff.
883                    } finally {
884                        ... // do more stuff.
885                    }
886
887                    // completionTypeRegister may be anything here depending on what
888                    // was executed in the inner try-finally block above.
889
890                    // Hence, finally completion here must be based on a saved copy of the
891                    // completionTypeRegister when we entered this finally block.
892                }
893
894            Detail 2: the finally completion for CompletionType::Throw must always explicitly
895            check if the savedCompletionTypeRegister is CompletionType::Throw before throwing.
896            We cannot imply that it is so from the Throw case being last.  Here's why:
897
898                // completionTypeRegister is CompletionType::Normal here.
899                try {
900                    return "r1"; // Sets completionTypeRegister to CompletionType::Return;
901                } finally {
902                    // completionTypeRegister is CompletionType::Return here.
903
904                    try {
905                        ... // do stuff.  No abrupt completions.
906                    } finally {
907                        // completionTypeRegister is CompletionType::Return here (from the outer try-finally).
908                        // savedCompletionTypeRegister is set to completionTypeRegister (i.e. CompletionType::Return) here.
909
910                        ... // do more stuff.  No abrupt completions.
911
912                        // Unless there's an abrupt completion since entering the outer
913                        // finally block, the savedCompletionTypeRegister will remain set
914                        // to CompletionType::Return.  If we don't explicitly check if the
915                        // savedCompletionTypeRegister is CompletionType::Throw before
916                        // throwing here, we'll end up erroneously throwing "r1".
917                    }
918
919                    ...
920                }
921
922         6. restoreScopeRegister()
923        
924            Since the needed scope objects are always stored in a local, we can restore
925            the scope register by simply moving from that local instead of going through
926            op_get_parent_scope.
927
928         7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
929            This makes it easier to keep a pointer to the FinallyContext on that stack,
930            and not have to worry about the vector being realloc'ed due to resizing. 
931
932         Performance appears to be neutral both on ES6SampleBench (run via cli) and the
933         JSC benchmarks.
934
935         Relevant spec references:
936         https://tc39.github.io/ecma262/#sec-completion-record-specification-type
937         https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
938
939         * bytecode/HandlerInfo.h:
940         (JSC::HandlerInfoBase::typeName):
941         * bytecompiler/BytecodeGenerator.cpp:
942         (JSC::BytecodeGenerator::generate):
943         (JSC::BytecodeGenerator::BytecodeGenerator):
944         (JSC::BytecodeGenerator::emitReturn):
945         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
946         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
947         (JSC::BytecodeGenerator::allocateAndEmitScope):
948         (JSC::BytecodeGenerator::pushTry):
949         (JSC::BytecodeGenerator::popTry):
950         (JSC::BytecodeGenerator::emitCatch):
951         (JSC::BytecodeGenerator::restoreScopeRegister):
952         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
953         (JSC::BytecodeGenerator::labelScopeDepth):
954         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
955         (JSC::BytecodeGenerator::popLocalControlFlowScope):
956         (JSC::BytecodeGenerator::emitEnumeration):
957         (JSC::BytecodeGenerator::emitIsNumber):
958         (JSC::BytecodeGenerator::emitYield):
959         (JSC::BytecodeGenerator::emitDelegateYield):
960         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
961         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
962         (JSC::BytecodeGenerator::emitFinallyCompletion):
963         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
964         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
965         (JSC::BytecodeGenerator::emitJumpIf):
966         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
967         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
968         (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
969         (JSC::BytecodeGenerator::emitPopScopes): Deleted.
970         (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
971         * bytecompiler/BytecodeGenerator.h:
972         (JSC::bytecodeOffsetToJumpID):
973         (JSC::FinallyJump::FinallyJump):
974         (JSC::FinallyContext::FinallyContext):
975         (JSC::FinallyContext::outerContext):
976         (JSC::FinallyContext::finallyLabel):
977         (JSC::FinallyContext::depth):
978         (JSC::FinallyContext::numberOfBreaksOrContinues):
979         (JSC::FinallyContext::incNumberOfBreaksOrContinues):
980         (JSC::FinallyContext::handlesReturns):
981         (JSC::FinallyContext::setHandlesReturns):
982         (JSC::FinallyContext::registerJump):
983         (JSC::FinallyContext::numberOfJumps):
984         (JSC::FinallyContext::jumps):
985         (JSC::ControlFlowScope::ControlFlowScope):
986         (JSC::ControlFlowScope::isLabelScope):
987         (JSC::ControlFlowScope::isFinallyScope):
988         (JSC::BytecodeGenerator::currentLexicalScopeIndex):
989         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
990         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
991         (JSC::BytecodeGenerator::completionTypeRegister):
992         (JSC::BytecodeGenerator::completionValueRegister):
993         (JSC::BytecodeGenerator::emitSetCompletionType):
994         (JSC::BytecodeGenerator::emitSetCompletionValue):
995         (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
996         * bytecompiler/NodesCodegen.cpp:
997         (JSC::ContinueNode::emitBytecode):
998         (JSC::BreakNode::emitBytecode):
999         (JSC::ReturnNode::emitBytecode):
1000         (JSC::TryNode::emitBytecode):
1001
1002 2016-12-22  Saam Barati  <sbarati@apple.com>
1003
1004         WebAssembly: Make the spec-tests/address.wast.js test pass
1005         https://bugs.webkit.org/show_bug.cgi?id=166429
1006         <rdar://problem/29793220>
1007
1008         Reviewed by Keith Miller.
1009
1010         Right now, provably out of bound loads/stores (given a load/store's constant
1011         offset) are not a validation error. However, we were failing to catch uint32_t
1012         overflows in release builds (we did have a debug assertion). To fix this,
1013         I now detect when uint32_t addition will overflow, and instead of emitting
1014         a normal load/store, I emit code that throws an out of bounds memory exception.
1015
1016         * wasm/WasmB3IRGenerator.cpp:
1017
1018 2016-12-22  Keith Miller  <keith_miller@apple.com>
1019
1020         WebAssembly: The validator should not allow unused stack entries at the end of a block
1021         https://bugs.webkit.org/show_bug.cgi?id=166411
1022
1023         Reviewed by Saam Barati.
1024
1025         This patch also cleans up some of the verbose mode logging.
1026
1027         * wasm/WasmB3IRGenerator.cpp:
1028         (JSC::Wasm::dumpExpressionStack):
1029         (JSC::Wasm::B3IRGenerator::dump):
1030         * wasm/WasmFunctionParser.h:
1031         * wasm/WasmValidate.cpp:
1032         (JSC::Wasm::dumpExpressionStack):
1033         (JSC::Wasm::Validate::dump):
1034
1035 2016-12-22  Saam Barati  <sbarati@apple.com>
1036
1037         WebAssembly: Make the spec-tests/start.wast.js test pass
1038         https://bugs.webkit.org/show_bug.cgi?id=166416
1039         <rdar://problem/29784532>
1040
1041         Reviewed by Yusuke Suzuki.
1042
1043         To make the test run, I had to fix two bugs:
1044         
1045         1. We weren't properly finding the start function. There was code
1046         that would try to find the start function from the list of *exported*
1047         functions. This is wrong; the start function is an index into the
1048         function index space, which is the space for *imports* and *local*
1049         functions. So the code was just wrong in this respect, and I've
1050         fixed it do the right thing. We weren't sure if this was originally
1051         allowed or not in the spec, but it has been decided that it is allowed
1052         and the spec-tests test for it: https://github.com/WebAssembly/design/issues/896
1053         
1054         2. We were emitting a breakpoint for Unreachable. Instead of crashing,
1055         this opcode needs to throw an exception when executing.
1056
1057         * wasm/WasmB3IRGenerator.cpp:
1058         * wasm/WasmExceptionType.h:
1059         * wasm/js/WebAssemblyModuleRecord.cpp:
1060         (JSC::WebAssemblyModuleRecord::link):
1061         (JSC::WebAssemblyModuleRecord::evaluate):
1062         * wasm/js/WebAssemblyModuleRecord.h:
1063
1064 2016-12-21  Keith Miller  <keith_miller@apple.com>
1065
1066         WebAssembly: Fix decode floating point constants in unreachable code
1067         https://bugs.webkit.org/show_bug.cgi?id=166400
1068
1069         Reviewed by Saam Barati.
1070
1071         We decoded these as variable length but they should be fixed length.
1072
1073         * wasm/WasmFunctionParser.h:
1074
1075 2016-12-21  Keith Miller  <keith_miller@apple.com>
1076
1077         WebAssembly: Allow br, br_if, and br_table to act as a return
1078         https://bugs.webkit.org/show_bug.cgi?id=166393
1079
1080         Reviewed by Saam Barati.
1081
1082         This patch allows br, br_if, and br_table to treat branching to
1083         the size of the control stack to act as a return. This change was
1084         made by adding a new block type to the wasm function parser,
1085         TopLevel. Adding this new block eliminates a lot of the special
1086         case code we had in the parser previously. The only special case
1087         we need is when the end opcode is parsed from the top level.  The
1088         B3 IR generator needs to automatically emit a return at that
1089         point.
1090
1091         Also, this patch adds the function number to validation errors
1092         in the function parser. The current error message is not helpful
1093         otherwise.
1094
1095         * wasm/WasmB3IRGenerator.cpp:
1096         (JSC::Wasm::B3IRGenerator::ControlData::dump):
1097         (JSC::Wasm::B3IRGenerator::addTopLevel):
1098         * wasm/WasmFunctionParser.h:
1099         * wasm/WasmPlan.cpp:
1100         (JSC::Wasm::Plan::parseAndValidateModule):
1101         (JSC::Wasm::Plan::run):
1102         * wasm/WasmValidate.cpp:
1103         (JSC::Wasm::Validate::ControlData::dump):
1104         (JSC::Wasm::Validate::Validate):
1105         (JSC::Wasm::Validate::addTopLevel):
1106         (JSC::Wasm::validateFunction):
1107
1108 2016-12-21  JF Bastien  <jfbastien@apple.com>
1109
1110         WebAssembly JS API: cleanup & pass VM around to {Compile/Runtime}Error
1111         https://bugs.webkit.org/show_bug.cgi?id=166295
1112         <rdar://problem/29762017>
1113
1114         Reviewed by Mark Lam.
1115
1116         Rename the create* functions, and pass VM around, as suggested for
1117         LinkError in #165805.
1118
1119         At the same time, use the default source appender when
1120         constructing these error types, which gives a nice map back to the
1121         original source as part of the error message. This is clearer when
1122         using the current frame, so add that as well.
1123
1124         * jit/ThunkGenerators.cpp:
1125         (JSC::throwExceptionFromWasmThunkGenerator):
1126         * wasm/js/JSWebAssemblyCompileError.cpp:
1127         (JSC::JSWebAssemblyCompileError::create):
1128         (JSC::createJSWebAssemblyCompileError):
1129         (JSC::createWebAssemblyCompileError): Deleted.
1130         * wasm/js/JSWebAssemblyCompileError.h:
1131         (JSC::JSWebAssemblyCompileError::create):
1132         * wasm/js/JSWebAssemblyRuntimeError.cpp:
1133         (JSC::JSWebAssemblyRuntimeError::create):
1134         * wasm/js/JSWebAssemblyRuntimeError.h:
1135         (JSC::JSWebAssemblyRuntimeError::create):
1136         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1137         (JSC::constructJSWebAssemblyCompileError):
1138         * wasm/js/WebAssemblyModuleConstructor.cpp:
1139         (JSC::WebAssemblyModuleConstructor::createModule):
1140         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1141         (JSC::constructJSWebAssemblyRuntimeError):
1142
1143 2016-12-21  Yusuke Suzuki  <utatane.tea@gmail.com>
1144
1145         [ES6] Fix modules document in features.json
1146         https://bugs.webkit.org/show_bug.cgi?id=166313
1147
1148         Reviewed by Saam Barati.
1149
1150         * features.json:
1151
1152 2016-12-20  Taras Tsugrii  <ttsugrii@fb.com>
1153
1154         Fix undefined behavior caused by macro expansion producing 'defined'
1155         https://bugs.webkit.org/show_bug.cgi?id=166047
1156
1157         Reviewed by Darin Adler.
1158
1159         * API/JSBase.h:
1160
1161 2016-12-20  Keith Miller  <keith_miller@apple.com>
1162
1163         Add support for global
1164         https://bugs.webkit.org/show_bug.cgi?id=165171
1165
1166         Reviewed by Filip Pizlo.
1167
1168         This patch adds spport for the global property on the global object.
1169         The global property spec is in stage three and is quite simple.
1170         For reference: http://tc39.github.io/proposal-global/
1171
1172         * runtime/JSGlobalObject.cpp:
1173
1174 2016-12-20  Saam Barati  <sbarati@apple.com>
1175
1176         WebAssembly: We should compile wasm functions in parallel
1177         https://bugs.webkit.org/show_bug.cgi?id=165993
1178
1179         Reviewed by Keith Miller.
1180
1181         This patch adds a very simple parallel compiler for Wasm code.
1182         This patch speeds up compiling the Unity headless benchmark by
1183         slightly more than 4x on my MBP. To make this safe, I perform
1184         all linking on the main thread. I also had to change some code
1185         inside Wasmb3IRGenerator to be thread safe.
1186
1187         * b3/air/AirCustom.h:
1188         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1189         * b3/air/AirGenerationContext.h:
1190         * wasm/WasmB3IRGenerator.cpp:
1191         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1192         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
1193         (JSC::Wasm::createJSToWasmWrapper):
1194         (JSC::Wasm::parseAndCompile):
1195         * wasm/WasmB3IRGenerator.h:
1196         * wasm/WasmCallingConvention.h:
1197         (JSC::Wasm::CallingConvention::setupFrameInPrologue):
1198         * wasm/WasmPlan.cpp:
1199         (JSC::Wasm::Plan::parseAndValidateModule):
1200         (JSC::Wasm::Plan::run):
1201         * wasm/WasmPlan.h:
1202
1203 2016-12-20  Brent Fulgham  <bfulgham@apple.com>
1204
1205         Address some style problems found by static analysis
1206         https://bugs.webkit.org/show_bug.cgi?id=165975
1207
1208         Reviewed by Alex Christensen.
1209
1210         Correct the const-correctness of functions that are implemented using stricter
1211         const declarations.
1212
1213         * inspector/agents/InspectorDebuggerAgent.h:
1214         * inspector/agents/InspectorHeapAgent.cpp:
1215         * inspector/agents/InspectorHeapAgent.h:
1216         * inspector/agents/InspectorRuntimeAgent.h:
1217         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1218         * inspector/agents/InspectorScriptProfilerAgent.h:
1219         * inspector/scripts/codegen/cpp_generator.py:
1220         (cpp_type_for_unchecked_formal_in_parameter): Update to match const declarations of
1221         implementation files.
1222         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1223         Rebaselined results for "const Ptr* const" syntax.
1224
1225 2016-12-20  JF Bastien  <jfbastien@apple.com>
1226
1227         WebAssembly: construct 32-bit encodedJSValue properly
1228         https://bugs.webkit.org/show_bug.cgi?id=166199
1229
1230         Reviewed by Mark Lam.
1231
1232         Constructing an encodedJSValue using `{ }` yields the wrong value
1233         on 32-bit platforms. WebAssembly doesn't currently target 32-bit
1234         platforms, but we may as well get it right.
1235
1236         * wasm/JSWebAssembly.cpp:
1237         (JSC::webAssemblyCompileFunc):
1238         (JSC::webAssemblyValidateFunc):
1239         * wasm/js/JSWebAssemblyHelpers.h:
1240         (JSC::toNonWrappingUint32):
1241         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
1242         (JSC::constructJSWebAssemblyCompileError):
1243         * wasm/js/WebAssemblyFunction.cpp:
1244         (JSC::callWebAssemblyFunction):
1245         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1246         (JSC::constructJSWebAssemblyInstance):
1247         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1248         (JSC::constructJSWebAssemblyMemory):
1249         * wasm/js/WebAssemblyModuleConstructor.cpp:
1250         (JSC::constructJSWebAssemblyModule):
1251         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
1252         (JSC::constructJSWebAssemblyRuntimeError):
1253         * wasm/js/WebAssemblyTableConstructor.cpp:
1254         (JSC::constructJSWebAssemblyTable):
1255         * wasm/js/WebAssemblyTablePrototype.cpp:
1256         (JSC::webAssemblyTableProtoFuncLength):
1257         (JSC::webAssemblyTableProtoFuncGrow):
1258         (JSC::webAssemblyTableProtoFuncGet):
1259         (JSC::webAssemblyTableProtoFuncSet):
1260
1261 2016-12-20  Dean Jackson  <dino@apple.com>
1262
1263         Remove INDIE_UI
1264         https://bugs.webkit.org/show_bug.cgi?id=165881
1265         <rdar://problem/29672532>
1266
1267         Reviewed by Simon Fraser.
1268
1269         The Indie UI work has been discontinued.
1270
1271         * Configurations/FeatureDefines.xcconfig:
1272
1273 2016-12-20  JF Bastien  <jfbastien@apple.com>
1274
1275         WebAssembly API: implement WebAssembly.LinkError
1276         https://bugs.webkit.org/show_bug.cgi?id=165805
1277         <rdar://problem/29747874>
1278
1279         Reviewed by Mark Lam.
1280
1281         As described here: https://github.com/WebAssembly/design/pull/901
1282         Some TypeError and RangeError are now converted to WebAssembly.LinkError.
1283
1284         * CMakeLists.txt: add files
1285         * DerivedSources.make: add autoget .lut.h files
1286         * JavaScriptCore.xcodeproj/project.pbxproj: add files
1287         * builtins/BuiltinNames.h: new name LinkError
1288         * runtime/JSGlobalObject.h: auto-register LinkError using existing macro magic
1289         * wasm/JSWebAssembly.h: make the new includes available
1290         * wasm/js/JSWebAssemblyLinkError.cpp: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.cpp.
1291         (JSC::JSWebAssemblyLinkError::create):
1292         (JSC::JSWebAssemblyLinkError::JSWebAssemblyLinkError):
1293         (JSC::createWebAssemblyLinkError):
1294         * wasm/js/JSWebAssemblyLinkError.h: Copied from Source/JavaScriptCore/wasm/JSWebAssemblyCompileError.h.
1295         (JSC::JSWebAssemblyLinkError::create):
1296         * wasm/js/WebAssemblyInstanceConstructor.cpp: update as per spec change
1297         (JSC::constructJSWebAssemblyInstance):
1298         * wasm/js/WebAssemblyLinkErrorConstructor.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.cpp.
1299         (JSC::constructJSWebAssemblyLinkError):
1300         (JSC::callJSWebAssemblyLinkError):
1301         (JSC::WebAssemblyLinkErrorConstructor::create):
1302         (JSC::WebAssemblyLinkErrorConstructor::createStructure):
1303         (JSC::WebAssemblyLinkErrorConstructor::finishCreation):
1304         (JSC::WebAssemblyLinkErrorConstructor::WebAssemblyLinkErrorConstructor):
1305         (JSC::WebAssemblyLinkErrorConstructor::getConstructData):
1306         (JSC::WebAssemblyLinkErrorConstructor::getCallData):
1307         * wasm/js/WebAssemblyLinkErrorConstructor.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorConstructor.h.
1308         * wasm/js/WebAssemblyLinkErrorPrototype.cpp: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.cpp.
1309         (JSC::WebAssemblyLinkErrorPrototype::create):
1310         (JSC::WebAssemblyLinkErrorPrototype::createStructure):
1311         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
1312         (JSC::WebAssemblyLinkErrorPrototype::WebAssemblyLinkErrorPrototype):
1313         * wasm/js/WebAssemblyLinkErrorPrototype.h: Copied from Source/JavaScriptCore/wasm/WebAssemblyCompileErrorPrototypr.h.
1314         * wasm/js/WebAssemblyModuleRecord.cpp: update as per spec change
1315         (JSC::dataSegmentFail):
1316         (JSC::WebAssemblyModuleRecord::evaluate):
1317
1318 2016-12-20  JF Bastien  <jfbastien@apple.com>
1319
1320         WebAssembly: unique function signatures
1321         https://bugs.webkit.org/show_bug.cgi?id=165957
1322         <rdar://problem/29735737>
1323
1324         Reviewed by Saam Barati.
1325
1326         Signatures in a Module's Type section can be duplicated, we
1327         therefore need to unique them so that call_indirect only needs to
1328         do a single integer compare to check that a callee's Signature is
1329         the same as the Signature declared at the call site. Without
1330         uniquing we'd either trap when duplicate Signatures are used, or
1331         we'd need to do multiple comparisons. This patch makes that narrow
1332         usecase function correctly.
1333
1334         There's further complication when calling from wasm to
1335         wasm, in which case the Signatures must also match. Such
1336         cross-instance calls will be improved in bug #165282, but this
1337         patch sets the groundwork for it:
1338
1339         - Signatures are now owned by SignatureInformation which lives on
1340           VM, and is shared by all Modules.
1341         - When parsing a Module, a Signature is created for every Type
1342           entry, and then uniqued by SignatureInformation's adopt
1343           method. Duplicate Signatures are dropped and the previous
1344           SignatureIndex is returned, new Signatures are adopted and a new
1345           SignatureIndex is created.
1346         - The SignatureIndex values are monotonic. 0 is used to represent
1347           invalid indices, which trap. This can only occur through Table.
1348         - SignatureInformation is used while generating code to map a
1349           SignatureIndex back to the Signature* when return / argument
1350           information is needed. This is a simple lookup into a Vector. It
1351           isn't used at runtime.
1352         - These Signatures live forever on VM because the bookkeeping
1353           likely isn't worth it. We may want to empty things out if all
1354           Modules die, this is tracked in bug #166037.
1355         - We can further improve things by bit-packing SignatureIndex with
1356           Code*, which is tracked by bug #165511.
1357
1358         * CMakeLists.txt:
1359         * JavaScriptCore.xcodeproj/project.pbxproj:
1360         * runtime/VM.h: wasm signatures are uniqued here, but aren't accessed frequently (only during parsing) so indirection is fine
1361         * wasm/WasmB3IRGenerator.cpp: use SignatureIndex instead of Signature* when appropriate, and when still using Signature* do so with its new API
1362         (JSC::Wasm::createJSToWasmWrapper):
1363         (JSC::Wasm::parseAndCompile):
1364         * wasm/WasmBinding.cpp:
1365         (JSC::Wasm::importStubGenerator): use SignatureIndex
1366         * wasm/WasmBinding.h:
1367         * wasm/WasmCallingConvention.h:
1368         (JSC::Wasm::CallingConvention::loadArguments):
1369         * wasm/WasmFormat.cpp: drive-by move of alloc/free functions to the implementation file, allows the .h file to drop an FastMalloc.h
1370         (JSC::Wasm::Segment::create):
1371         (JSC::Wasm::Segment::destroy):
1372         (JSC::Wasm::Segment::createPtr):
1373         * wasm/WasmFormat.h: move Signature to its own file
1374         (JSC::Wasm::CallableFunction::CallableFunction):
1375         * wasm/WasmFunctionParser.h:
1376         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
1377         * wasm/WasmModuleParser.cpp:
1378         * wasm/WasmModuleParser.h:
1379         (JSC::Wasm::ModuleParser::ModuleParser):
1380         * wasm/WasmParser.h:
1381         (JSC::Wasm::Parser<SuccessType>::Parser):
1382         * wasm/WasmPlan.cpp:
1383         (JSC::Wasm::Plan::parseAndValidateModule):
1384         (JSC::Wasm::Plan::run):
1385         * wasm/WasmSignature.cpp: Added.
1386         (JSC::Wasm::Signature::dump):
1387         (JSC::Wasm::Signature::hash):
1388         (JSC::Wasm::Signature::create):
1389         (JSC::Wasm::Signature::createInvalid):
1390         (JSC::Wasm::Signature::destroy):
1391         (JSC::Wasm::SignatureInformation::~SignatureInformation):
1392         (JSC::Wasm::SignatureInformation::adopt):
1393         (JSC::Wasm::SignatureInformation::get):
1394         * wasm/WasmSignature.h: Added.
1395         (JSC::Wasm::Signature::Signature):
1396         (JSC::Wasm::Signature::storage):
1397         (JSC::Wasm::Signature::allocatedSize):
1398         (JSC::Wasm::Signature::returnType):
1399         (JSC::Wasm::Signature::returnCount):
1400         (JSC::Wasm::Signature::argumentCount):
1401         (JSC::Wasm::Signature::argument):
1402         (JSC::Wasm::Signature::operator==):
1403         (JSC::Wasm::SignatureHash::empty):
1404         (JSC::Wasm::SignatureHash::deleted):
1405         (JSC::Wasm::SignatureHash::SignatureHash):
1406         (JSC::Wasm::SignatureHash::operator==):
1407         (JSC::Wasm::SignatureHash::equal):
1408         (JSC::Wasm::SignatureHash::hash):
1409         (JSC::Wasm::SignatureHash::isHashTableDeletedValue):
1410         * wasm/WasmValidate.cpp:
1411         (JSC::Wasm::validateFunction):
1412         * wasm/WasmValidate.h:
1413         * wasm/js/JSWebAssemblyInstance.cpp:
1414         (JSC::JSWebAssemblyInstance::create):
1415         * wasm/js/JSWebAssemblyModule.h:
1416         (JSC::JSWebAssemblyModule::signatureForFunctionIndexSpace):
1417         * wasm/js/JSWebAssemblyTable.cpp:
1418         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1419         (JSC::JSWebAssemblyTable::clearFunction):
1420         (JSC::JSWebAssemblyTable::setFunction):
1421         * wasm/js/WebAssemblyFunction.cpp:
1422         (JSC::callWebAssemblyFunction):
1423         (JSC::WebAssemblyFunction::call):
1424         (JSC::WebAssemblyFunction::create):
1425         (JSC::WebAssemblyFunction::WebAssemblyFunction):
1426         (JSC::WebAssemblyFunction::finishCreation):
1427         * wasm/js/WebAssemblyFunction.h:
1428         (JSC::WebAssemblyFunction::signatureIndex):
1429         * wasm/js/WebAssemblyModuleRecord.cpp:
1430         (JSC::WebAssemblyModuleRecord::link):
1431         (JSC::WebAssemblyModuleRecord::evaluate):
1432
1433 2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>
1434
1435         Modernize for loops in JSC
1436         https://bugs.webkit.org/show_bug.cgi?id=166060
1437
1438         Reviewed by Yusuke Suzuki.
1439
1440         * API/JSCallbackObject.h:
1441         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
1442         * bytecode/CodeBlock.cpp:
1443         (JSC::CodeBlock::dumpBytecode):
1444         (JSC::CodeBlock::propagateTransitions):
1445         (JSC::CodeBlock::stronglyVisitStrongReferences):
1446         (JSC::CodeBlock::stronglyVisitWeakReferences):
1447         (JSC::CodeBlock::jettison):
1448         (JSC::CodeBlock::getArrayProfile):
1449         (JSC::CodeBlock::tallyFrequentExitSites):
1450         (JSC::CodeBlock::nameForRegister):
1451         * bytecompiler/BytecodeGenerator.cpp:
1452         (JSC::BytecodeGenerator::generate):
1453         (JSC::BytecodeGenerator::BytecodeGenerator):
1454         * bytecompiler/NodesCodegen.cpp:
1455         (JSC::ObjectPatternNode::bindValue):
1456         * debugger/Debugger.cpp:
1457         (JSC::Debugger::applyBreakpoints):
1458         * dfg/DFGCPSRethreadingPhase.cpp:
1459         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlock):
1460         * dfg/DFGClobberSet.cpp:
1461         (JSC::DFG::ClobberSet::setOf):
1462         * dfg/DFGDesiredIdentifiers.cpp:
1463         (JSC::DFG::DesiredIdentifiers::reallyAdd):
1464         * dfg/DFGGraph.cpp:
1465         (JSC::DFG::Graph::visitChildren):
1466         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1467         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1468         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1469         * dfg/DFGJITCompiler.cpp:
1470         (JSC::DFG::JITCompiler::link):
1471         * dfg/DFGLICMPhase.cpp:
1472         (JSC::DFG::LICMPhase::run):
1473         * dfg/DFGMaximalFlushInsertionPhase.cpp:
1474         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
1475         * dfg/DFGPutStackSinkingPhase.cpp:
1476         * dfg/DFGSpeculativeJIT.cpp:
1477         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1478         (JSC::DFG::SpeculativeJIT::linkBranches):
1479         * dfg/DFGStructureRegistrationPhase.cpp:
1480         (JSC::DFG::StructureRegistrationPhase::run):
1481         * dfg/DFGTypeCheckHoistingPhase.cpp:
1482         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1483         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1484         * dfg/DFGValidate.cpp:
1485         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
1486         (JSC::DFG::VirtualRegisterAllocationPhase::run):
1487         * heap/HeapVerifier.cpp:
1488         (JSC::trimDeadObjectsFromList):
1489         (JSC::HeapVerifier::trimDeadObjects):
1490         * heap/LiveObjectList.cpp:
1491         (JSC::LiveObjectList::findObject):
1492         * heap/MarkedAllocator.cpp:
1493         (JSC::MarkedAllocator::isPagedOut):
1494         * inspector/ScriptCallStack.cpp:
1495         (Inspector::ScriptCallStack::firstNonNativeCallFrame):
1496         * jit/JIT.cpp:
1497         (JSC::JIT::link):
1498         * parser/VariableEnvironment.cpp:
1499         (JSC::VariableEnvironment::markAllVariablesAsCaptured):
1500         (JSC::VariableEnvironment::hasCapturedVariables):
1501         * runtime/FunctionHasExecutedCache.cpp:
1502         (JSC::FunctionHasExecutedCache::hasExecutedAtOffset):
1503         (JSC::FunctionHasExecutedCache::getFunctionRanges):
1504         * runtime/JSPropertyNameEnumerator.cpp:
1505         (JSC::JSPropertyNameEnumerator::visitChildren):
1506         * runtime/TypeProfiler.cpp:
1507         (JSC::TypeProfiler::findLocation):
1508         * runtime/TypeSet.cpp:
1509         (JSC::TypeSet::addTypeInformation):
1510         (JSC::TypeSet::dumpTypes):
1511         * runtime/VM.cpp:
1512         (JSC::VM::gatherConservativeRoots):
1513         * runtime/WeakMapData.cpp:
1514         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
1515         (JSC::WeakMapData::DeadKeyCleaner::finalizeUnconditionally):
1516         * tools/ProfileTreeNode.h:
1517         (JSC::ProfileTreeNode::dumpInternal):
1518         * yarr/YarrInterpreter.cpp:
1519         (JSC::Yarr::ByteCompiler::emitDisjunction):
1520
1521 2016-12-20  Konstantin Tokarev  <annulen@yandex.ru>
1522
1523         __cpuid() requires <intrin.h> to be included
1524         https://bugs.webkit.org/show_bug.cgi?id=166051
1525
1526         Reviewed by Yusuke Suzuki.
1527
1528         * assembler/MacroAssemblerX86Common.h:
1529
1530 2016-12-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1531
1532         [ES6] Enable ES6 Modules
1533         https://bugs.webkit.org/show_bug.cgi?id=165849
1534
1535         Reviewed by Geoffrey Garen.
1536
1537         * features.json:
1538
1539 2016-12-19  Mark Lam  <mark.lam@apple.com>
1540
1541         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 2: Rollout r209952.
1542         https://bugs.webkit.org/show_bug.cgi?id=166049
1543
1544         Not reviewed.
1545
1546         * bytecode/HandlerInfo.h:
1547         (JSC::HandlerInfoBase::typeName):
1548         * bytecompiler/BytecodeGenerator.cpp:
1549         (JSC::BytecodeGenerator::generate):
1550         (JSC::BytecodeGenerator::BytecodeGenerator):
1551         (JSC::BytecodeGenerator::emitReturn):
1552         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1553         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope):
1554         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
1555         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope):
1556         (JSC::BytecodeGenerator::emitComplexPopScopes):
1557         (JSC::BytecodeGenerator::emitPopScopes):
1558         (JSC::BytecodeGenerator::pushTry):
1559         (JSC::BytecodeGenerator::popTryAndEmitCatch):
1560         (JSC::BytecodeGenerator::labelScopeDepth):
1561         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
1562         (JSC::BytecodeGenerator::popLocalControlFlowScope):
1563         (JSC::BytecodeGenerator::emitEnumeration):
1564         (JSC::BytecodeGenerator::emitYield):
1565         (JSC::BytecodeGenerator::emitDelegateYield):
1566         (JSC::BytecodeGenerator::popTry): Deleted.
1567         (JSC::BytecodeGenerator::emitCatch): Deleted.
1568         (JSC::BytecodeGenerator::restoreScopeRegister): Deleted.
1569         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex): Deleted.
1570         (JSC::BytecodeGenerator::emitIsNumber): Deleted.
1571         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded): Deleted.
1572         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded): Deleted.
1573         (JSC::BytecodeGenerator::emitFinallyCompletion): Deleted.
1574         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
1575         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
1576         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
1577         * bytecompiler/BytecodeGenerator.h:
1578         (JSC::BytecodeGenerator::isInFinallyBlock):
1579         (JSC::FinallyJump::FinallyJump): Deleted.
1580         (JSC::FinallyContext::FinallyContext): Deleted.
1581         (JSC::FinallyContext::outerContext): Deleted.
1582         (JSC::FinallyContext::finallyLabel): Deleted.
1583         (JSC::FinallyContext::depth): Deleted.
1584         (JSC::FinallyContext::numberOfBreaksOrContinues): Deleted.
1585         (JSC::FinallyContext::incNumberOfBreaksOrContinues): Deleted.
1586         (JSC::FinallyContext::handlesReturns): Deleted.
1587         (JSC::FinallyContext::setHandlesReturns): Deleted.
1588         (JSC::FinallyContext::registerJump): Deleted.
1589         (JSC::FinallyContext::numberOfJumps): Deleted.
1590         (JSC::FinallyContext::jumps): Deleted.
1591         (JSC::ControlFlowScope::ControlFlowScope): Deleted.
1592         (JSC::ControlFlowScope::isLabelScope): Deleted.
1593         (JSC::ControlFlowScope::isFinallyScope): Deleted.
1594         (JSC::BytecodeGenerator::currentLexicalScopeIndex): Deleted.
1595         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
1596         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
1597         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
1598         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
1599         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
1600         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
1601         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
1602         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
1603         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
1604         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
1605         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
1606         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
1607         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
1608         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
1609         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
1610         * bytecompiler/NodesCodegen.cpp:
1611         (JSC::ContinueNode::emitBytecode):
1612         (JSC::BreakNode::emitBytecode):
1613         (JSC::ReturnNode::emitBytecode):
1614         (JSC::TryNode::emitBytecode):
1615
1616 2016-12-19  Mark Lam  <mark.lam@apple.com>
1617
1618         Rolling out r209974 and r209952. They break some websites in mysterious ways. Step 1: Rollout r209974.
1619         https://bugs.webkit.org/show_bug.cgi?id=166049
1620
1621         Not reviewed.
1622
1623         * bytecompiler/BytecodeGenerator.cpp:
1624         (JSC::BytecodeGenerator::emitEnumeration):
1625         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1626         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1627         (JSC::BytecodeGenerator::emitFinallyCompletion):
1628         (JSC::BytecodeGenerator::allocateFinallyRegisters):
1629         (JSC::BytecodeGenerator::releaseFinallyRegisters):
1630         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
1631         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters): Deleted.
1632         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters): Deleted.
1633         (JSC::BytecodeGenerator::emitJumpIfCompletionType): Deleted.
1634         * bytecompiler/BytecodeGenerator.h:
1635         (JSC::FinallyJump::FinallyJump):
1636         (JSC::FinallyContext::registerJump):
1637         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
1638         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
1639         (JSC::BytecodeGenerator::finallyActionRegister):
1640         (JSC::BytecodeGenerator::finallyReturnValueRegister):
1641         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
1642         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
1643         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
1644         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
1645         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
1646         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
1647         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
1648         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
1649         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
1650         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
1651         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
1652         (JSC::bytecodeOffsetToJumpID): Deleted.
1653         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope): Deleted.
1654         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope): Deleted.
1655         (JSC::BytecodeGenerator::completionTypeRegister): Deleted.
1656         (JSC::BytecodeGenerator::completionValueRegister): Deleted.
1657         (JSC::BytecodeGenerator::emitSetCompletionType): Deleted.
1658         (JSC::BytecodeGenerator::emitSetCompletionValue): Deleted.
1659         * bytecompiler/NodesCodegen.cpp:
1660         (JSC::TryNode::emitBytecode):
1661
1662 2016-12-19  Joseph Pecoraro  <pecoraro@apple.com>
1663
1664         Web Inspector: Assertion seen in InspectorDebuggerAgent::refAsyncCallData with Inspector open
1665         https://bugs.webkit.org/show_bug.cgi?id=166034
1666         <rdar://problem/29554366>
1667
1668         Reviewed by Brian Burg.
1669
1670         * inspector/agents/InspectorDebuggerAgent.cpp:
1671         (Inspector::InspectorDebuggerAgent::refAsyncCallData):
1672         Remove assertion. This assert can happen if the currently executing callback
1673         was just explicitly cancelled by script. Existing code already handles if
1674         no async data was found for the given identifier.
1675
1676 2016-12-18  Saam Barati  <sbarati@apple.com>
1677
1678         WebAssembly: Implement the WebAssembly.compile and WebAssembly.validate
1679         https://bugs.webkit.org/show_bug.cgi?id=165936
1680
1681         Reviewed by Mark Lam.
1682
1683         The APIs are documented here:
1684         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblycompile
1685         - https://github.com/WebAssembly/design/blob/master/JS.md#webassemblyvalidate
1686
1687         * wasm/JSWebAssembly.cpp:
1688         (JSC::webAssemblyCompileFunc):
1689         (JSC::webAssemblyValidateFunc):
1690         (JSC::JSWebAssembly::finishCreation):
1691         * wasm/WasmPlan.cpp:
1692         (JSC::Wasm::Plan::parseAndValidateModule):
1693         (JSC::Wasm::Plan::run):
1694         * wasm/WasmPlan.h:
1695         * wasm/js/JSWebAssemblyHelpers.h:
1696         (JSC::getWasmBufferFromValue):
1697         * wasm/js/WebAssemblyModuleConstructor.cpp:
1698         (JSC::constructJSWebAssemblyModule):
1699         (JSC::callJSWebAssemblyModule):
1700         (JSC::WebAssemblyModuleConstructor::createModule):
1701         * wasm/js/WebAssemblyModuleConstructor.h:
1702
1703 2016-12-18  Mark Lam  <mark.lam@apple.com>
1704
1705         Rename finallyActionRegister to completionTypeRegister and only store int JSValues in it.
1706         https://bugs.webkit.org/show_bug.cgi?id=165979
1707
1708         Reviewed by Saam Barati.
1709
1710         This patch makes it so that we only store int JSValues in the finallyActionRegister
1711         thereby making type prediction on this register more successful for JITs.  In so
1712         doing, we are able to get some additional benefits:
1713
1714         1. Renamed the following:
1715            FinallyRegistersScope => CompletionRecordScope
1716            finallyActionRegister => completionTypeRegister
1717            finallyReturnValueRegister => completionValueRegister
1718
1719            These new names are more in line with the ES spec, which describes these
1720            values as the completion record and its type and value properties.
1721            https://tc39.github.io/ecma262/#sec-completion-record-specification-type
1722
1723         2. We now think of the Break and Continue jumpIDs as encodings of CompletionType
1724            (in our implementation of completion type).  As a result, we only need one of
1725            each of the emitter methods for getting, setting, and compare-and-jump on the
1726            completion type.  The code using these methods also reads much clearer now.  
1727
1728         3. Finally blocks' op_catch should now always pop the caught Exception object into
1729            the completionValueRegister instead of the completionTypeRegister (formerly
1730            finallyActionRegister). 
1731
1732         Also removed the restoreScopeRegister() call in the IteratorClose catch block
1733         because that is an implementation specific synthesized catch block, and we
1734         can guarantee that it never needs to resolve any symbols from the scope.  Hence,
1735         there is no need to restore the scope register.
1736
1737         * bytecompiler/BytecodeGenerator.cpp:
1738         (JSC::BytecodeGenerator::emitEnumeration):
1739         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1740         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
1741         (JSC::BytecodeGenerator::emitFinallyCompletion):
1742         (JSC::BytecodeGenerator::allocateCompletionRecordRegisters):
1743         (JSC::BytecodeGenerator::releaseCompletionRecordRegisters):
1744         (JSC::BytecodeGenerator::emitJumpIfCompletionType):
1745         (JSC::BytecodeGenerator::allocateFinallyRegisters): Deleted.
1746         (JSC::BytecodeGenerator::releaseFinallyRegisters): Deleted.
1747         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf): Deleted.
1748         * bytecompiler/BytecodeGenerator.h:
1749         (JSC::bytecodeOffsetToJumpID):
1750         (JSC::FinallyJump::FinallyJump):
1751         (JSC::FinallyContext::registerJump):
1752         (JSC::BytecodeGenerator::CompletionRecordScope::CompletionRecordScope):
1753         (JSC::BytecodeGenerator::CompletionRecordScope::~CompletionRecordScope):
1754         (JSC::BytecodeGenerator::completionTypeRegister):
1755         (JSC::BytecodeGenerator::completionValueRegister):
1756         (JSC::BytecodeGenerator::emitSetCompletionType):
1757         (JSC::BytecodeGenerator::emitSetCompletionValue):
1758         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope): Deleted.
1759         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope): Deleted.
1760         (JSC::BytecodeGenerator::finallyActionRegister): Deleted.
1761         (JSC::BytecodeGenerator::finallyReturnValueRegister): Deleted.
1762         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion): Deleted.
1763         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion): Deleted.
1764         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID): Deleted.
1765         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister): Deleted.
1766         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion): Deleted.
1767         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump): Deleted.
1768         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion): Deleted.
1769         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion): Deleted.
1770         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion): Deleted.
1771         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow): Deleted.
1772         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID): Deleted.
1773         * bytecompiler/NodesCodegen.cpp:
1774         (JSC::TryNode::emitBytecode):
1775
1776 2016-12-17  Saam Barati  <sbarati@apple.com>
1777
1778         WebAssembly: WasmB3IRGenerator uses WarmAny as a ValueRep but expects the incoming value to be a register
1779         https://bugs.webkit.org/show_bug.cgi?id=165989
1780
1781         Reviewed by Mark Lam.
1782
1783         The input should be constrained to a register to match what
1784         the patchpoint code expects.
1785
1786         * wasm/WasmB3IRGenerator.cpp:
1787
1788 2016-12-17  Saam Barati  <sbarati@apple.com>
1789
1790         WebAssembly: Change a RELEASE_ASSERT_NOT_REACHED to a jit.breakpoint() for now to allow us to run some wasm benchmarks
1791         https://bugs.webkit.org/show_bug.cgi?id=165990
1792
1793         Reviewed by Mark Lam.
1794
1795         * wasm/WasmBinding.cpp:
1796         (JSC::Wasm::importStubGenerator):
1797
1798 2016-12-16  Joseph Pecoraro  <pecoraro@apple.com>
1799
1800         JSContext Inspector: Avoid some possible exceptions inspecting a JSContext
1801         https://bugs.webkit.org/show_bug.cgi?id=165986
1802         <rdar://problem/29551379>
1803
1804         Reviewed by Matt Baker.
1805
1806         * inspector/InjectedScriptSource.js:
1807         (InjectedScript.prototype.processProperties):
1808         Prefer String.prototype.endsWith now that it is available.
1809
1810         (InjectedScript.prototype._describe):
1811         Prefer Function.prototype.toString for converting functions to String.
1812         Previously we were doing String(f) which would to Symbol.toPrimitive
1813         conversion which seems unnecessary here.
1814
1815 2016-12-16  Michael Catanzaro  <mcatanzaro@igalia.com>
1816
1817         Unreviewed, fix GCC 6 build failure after r209952
1818
1819         Return false, not nullptr, in function returning bool.
1820
1821         * bytecompiler/BytecodeGenerator.cpp:
1822         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
1823
1824 2016-12-16  Saam Barati  <sbarati@apple.com>
1825
1826         WebAssembly: We still have some incorrect parsing productions inside unreachable code
1827         https://bugs.webkit.org/show_bug.cgi?id=165981
1828
1829         Reviewed by Keith Miller.
1830
1831         This hardens our parsing for CallIndirect and Loop/Block/If to be exactly like their reachable variant.
1832         
1833         It also fixes a more nefarious bug in which we were decoding an extra varuint32
1834         for Br/BrIf inside unreachable code.
1835
1836         * wasm/WasmFunctionParser.h:
1837
1838 2016-12-16  Filip Pizlo  <fpizlo@apple.com>
1839
1840         CellState should have members with accurate names
1841         https://bugs.webkit.org/show_bug.cgi?id=165969
1842
1843         Reviewed by Mark Lam.
1844         
1845         This once again renames the members in CellState. I wanted to convey the following
1846         pieces of information in the names:
1847         
1848         - What does the state mean for Generational GC?
1849         - What does the state mean for Concurrent GC?
1850         - Does the state guarantee what it means, or is there some contingency?
1851         
1852         The names I came up with are:
1853         
1854         PossiblyOldOrBlack: An object in this state may be old, or may be black, depending on
1855             other things. If the mark bit is set then the object is either black or being
1856             blackened as we speak. It's going to survive the GC, so it will be old, but may be
1857             new now. In between GCs, objects in this state are definitely old. If the mark bit
1858             is not set, then the object is actually old and white.
1859         
1860         DefinitelyNewAndWhite: The object was just allocated so it is white (not marked) and
1861             new.
1862         
1863         DefinitelyGrey: The object is definitely grey - it will be rescanned in the future. It
1864             may be new or old depending on other things.
1865
1866         * heap/CellState.h:
1867         * heap/Heap.cpp:
1868         (JSC::Heap::addToRememberedSet):
1869         (JSC::Heap::writeBarrierSlowPath):
1870         * heap/SlotVisitor.cpp:
1871         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
1872         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
1873         (JSC::SlotVisitor::appendToMarkStack):
1874         (JSC::SlotVisitor::visitChildren):
1875         * runtime/JSCellInlines.h:
1876         (JSC::JSCell::JSCell):
1877         * runtime/StructureIDBlob.h:
1878         (JSC::StructureIDBlob::StructureIDBlob):
1879
1880 2016-12-16  Saam Barati  <sbarati@apple.com>
1881
1882         B3::DoubleToFloatReduction will accidentally convince itself it converted a Phi from Double to Float and then convert uses of that Phi into a use of FloatToDouble(@Phi)
1883         https://bugs.webkit.org/show_bug.cgi?id=165946
1884
1885         Reviewed by Keith Miller.
1886
1887         This was happening because the phase will convert some Phi nodes
1888         from Double to Float. However, one place that did this conversion
1889         forgot to first check if the Phi was already a Float. If it's already
1890         a Float, a later part of the phase will be buggy if the phase claims that it has
1891         converted it from Double->Float. The reason is that at the end of the
1892         phase, we'll look for all uses of former Double Phi nodes and make them
1893         be a use of ConvertFloatToDouble on the Phi, instead of a use of the Phi itself.
1894         This is clearly wrong if the Phi were Float to begin with (and
1895         therefore, the uses were Float uses to begin with).
1896
1897         * b3/B3ReduceDoubleToFloat.cpp:
1898         * b3/testb3.cpp:
1899         (JSC::B3::testReduceFloatToDoubleValidates):
1900         (JSC::B3::run):
1901
1902 2016-12-16  Mark Lam  <mark.lam@apple.com>
1903
1904         De-duplicate finally blocks.
1905         https://bugs.webkit.org/show_bug.cgi?id=160168
1906
1907         Reviewed by Keith Miller.
1908
1909         JS execution can arrive at a finally block when there are abrupt completions from
1910         its try or catch block.  The abrupt completion types include Break,
1911         Continue, Return, and Throw.  The non-abrupt completion type is called Normal
1912         (i.e. the case of a try block falling through to the finally block).
1913
1914         Previously, we enable each of these paths for abrupt completion (except for Throw)
1915         to run the finally block code by duplicating the finally block code at each of
1916         the sites that trigger those completions.  This patch fixes the implementation so
1917         that each of these abrupt completions will set a finallyActionRegister (plus a
1918         finallyReturnValueRegister for CompletionType::Return) and then jump to the
1919         relevant finally blocks, and continue to thread through subsequent outer finally
1920         blocks until execution reaches the outermost finally block that the completion
1921         type dictates.  We no longer duplicate the finally block code.
1922
1923         The implementation details:
1924         1. We allocate a pair of finallyActionRegister and finallyReturnValueRegister
1925            just before entering the outermost try-catch-finally scope.
1926
1927            On allocating the registers, we set them to the empty JSValue.  This serves
1928            to set the completion type to CompletionType::Normal (see (2) below).
1929
1930         2. The finallyActionRegister serves 2 purpose:
1931            a. indicates the CompletionType that triggered entry into the finally block.
1932
1933               This is how we encode the completion type in the finallyActionRegister:
1934               1. CompletionType::Normal
1935                  - finallyActionRegister is set to the empty JSValue.
1936               2. CompletionType::Break
1937                  - finallyActionRegister is set to the int jumpID for the site of the break statement.
1938               3. CompletionType::Continue
1939                  - finallyActionRegister is set to the int jumpID for the site of the continue statement.
1940               4. CompletionType::Return
1941                  - finallyActionRegister is set to CompletionType::Return as an int JSValue.
1942                  - finallyReturnValueRegister is set to the value to be returned. 
1943               5. CompletionType::Throw
1944                  - finallyActionRegister is set to the exception object that was caught by the finally block.
1945
1946               Hence, if the finallyActionRegister can either be:
1947               1. empty i.e. we're handling CompletionType::Normal.
1948               2. an int JSValue i.e. we're handling CompletionType::Break, Continue, or Return.
1949               3. an object i.e. we're handling CompletionType::Throw.
1950
1951            b. stores the exception caught in the finally block if we're handing
1952               CompletionType::Throw.
1953
1954         3. Each finally block will have 2 entries:
1955            a. the entry via throw.
1956            b. the normal entry.
1957
1958            The entry via throw is recorded in the codeBlock's exception table, and can
1959            only be jumped to by the VM's exception handling mechanism.
1960
1961            The normal entry is recorded in a FinallyContext (at bytecode generation time
1962            only) and is jumped to when we want enter the finally block due any of the
1963            other CompletionTypes.
1964
1965         4. CompletionType::Normal
1966            ======================
1967            We encounter this when falling through from a try or catch block to the finally block.  
1968            
1969            For the try block case, since finallyActionRegister is set to Normal by default,
1970            there's nothing more that needs to be done.
1971
1972            For the catch block case, since we entered the catch block with an exception,
1973            finallyActionRegister may be set to Throw.  We'll need to set it to Normal
1974            before jumping to the finally block's normal entry.
1975
1976            CompletionType::Break
1977            =====================
1978            When we emit bytecode for the BreakNode, we check if we have any FinallyContexts
1979            that we need to service before jumping to the breakTarget.  If we do, then:
1980            a. we'll register a jumpID along with the breakTarget with the outermost FinallyContext.
1981            b. we'll also increment the numberOfBreaksOrContinues count in each FinallyContext
1982               from the innermost to the outermost.
1983            c. instead of emitting bytecode to jump to the breakTarget, we:
1984               1. emit bytecode to set finallyActionRegister to the jumpID.
1985               b. emit bytecode to jump to the normal entry of the innermost finally block.
1986
1987            Each finally block will take care of cascading to the next outer finally block
1988            as needed (see (5) below).
1989
1990            CompletionType::Continue
1991            ========================
1992            Since continues and breaks work the same way (i.e. with a jump), we handle this
1993            exactly the same way as CompletionType::Break, except that we use the
1994            continueTarget instead of the breakTarget.
1995
1996            CompletionType::Return
1997            ======================
1998            When we emit bytecode for the ReturnNode, we check if we have any FinallyContexts
1999            at all on the m_controlFlowScopeStack.
2000
2001            If so, then instead of emitting op_ret, we:
2002               1. emit bytecode to set finallyActionRegister to the CompletionType::Return.
2003               1. emit bytecode to move the return value into finallyReturnValueRegister.
2004               2. emit bytecode to jump to the normal entry of the innermost finally block.
2005
2006            Each finally block will take care of cascading to the next outer finally block
2007            as needed (see (5) below).
2008
2009            CompletionType::Throw
2010            ======================
2011            The op_catch of a finally block will always store the caught exception object
2012            in the finallyActionRegister.  This means we're handling CompletionType::Throw
2013            (see (2) above).
2014
2015         5. What happens in each finally block?
2016            ==================================
2017            Only the finally block's entry via throw will have an op_catch that catches the
2018            pending exception (and stores it in the finallyActionRegister).  This throw
2019            entry then falls through to the normal entry.
2020
2021            The finally block's normal entry will restore the scope of the finally block
2022            and proceed to execute its code.
2023
2024            At the end of the finally block (see emitFinallyCompletion()), the finally
2025            block will check the finallyActionRegister for each completion type in the
2026            following order:
2027            
2028            a. CompletionType::Normal: jump to the code after the finally block as
2029               designated by a normalCompletion label.
2030
2031            b. CompletionType::Break and Continue:
2032               If the FinallyContext for this block has registered FinallyJumps, we'll
2033               check for the jumpIDs against the finallyActionRegister.  If the jumpID
2034               matches, jump to the corresponding jumpTarget.
2035
2036               If no jumpIDs match but the FinallyContext's numberOfBreaksOrContinues is
2037               greater than the number of registered FinallyJumps, then this means that
2038               we have a Break or Continue that needs to be handled by an outer finally
2039               block.  In that case, jump to the outer finally block's normal entry.
2040               
2041            c. CompletionType::Return:
2042               If this finally block is not the outermost and finallyActionRegister contains
2043               CompletionType::Return, then jump to the outer finally block's normal entry.
2044
2045               Otherwise, if this finally block is the outermost and finallyActionRegister
2046               contains CompletionType::Return, then execute op_ret and return the value
2047               in finallyReturnValueRegister.
2048
2049            d. CompletionType::Throw:
2050               If we're not handling any of the above cases, then just throw the
2051               finallyActionRegister which contains the exception to re-throw.
2052
2053         6. restoreScopeRegister()
2054         
2055            Since the needed scope objects are always stored in a local, we can restore
2056            the scope register by simply moving from that local instead of going through
2057            op_get_parent_scope.
2058
2059         7. m_controlFlowScopeStack needs to be a SegmentedVector instead of a Vector.
2060            This makes it easier to keep a pointer to the FinallyContext on that stack,
2061            and not have to worry about the vector being realloc'ed due to resizing. 
2062
2063         Performance appears to be neutral both on ES6SampleBench (run via cli) and the
2064         JSC benchmarks.
2065
2066         Relevant spec references:
2067         https://tc39.github.io/ecma262/#sec-completion-record-specification-type
2068         https://tc39.github.io/ecma262/#sec-try-statement-runtime-semantics-evaluation
2069
2070         * bytecode/HandlerInfo.h:
2071         (JSC::HandlerInfoBase::typeName):
2072         * bytecompiler/BytecodeGenerator.cpp:
2073         (JSC::BytecodeGenerator::generate):
2074         (JSC::BytecodeGenerator::BytecodeGenerator):
2075         (JSC::BytecodeGenerator::emitReturn):
2076         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
2077         (JSC::BytecodeGenerator::popFinallyControlFlowScope):
2078         (JSC::BytecodeGenerator::allocateAndEmitScope):
2079         (JSC::BytecodeGenerator::pushTry):
2080         (JSC::BytecodeGenerator::popTry):
2081         (JSC::BytecodeGenerator::emitCatch):
2082         (JSC::BytecodeGenerator::restoreScopeRegister):
2083         (JSC::BytecodeGenerator::labelScopeDepthToLexicalScopeIndex):
2084         (JSC::BytecodeGenerator::labelScopeDepth):
2085         (JSC::BytecodeGenerator::pushLocalControlFlowScope):
2086         (JSC::BytecodeGenerator::popLocalControlFlowScope):
2087         (JSC::BytecodeGenerator::emitEnumeration):
2088         (JSC::BytecodeGenerator::emitIsNumber):
2089         (JSC::BytecodeGenerator::emitYield):
2090         (JSC::BytecodeGenerator::emitDelegateYield):
2091         (JSC::BytecodeGenerator::emitJumpViaFinallyIfNeeded):
2092         (JSC::BytecodeGenerator::emitReturnViaFinallyIfNeeded):
2093         (JSC::BytecodeGenerator::emitFinallyCompletion):
2094         (JSC::BytecodeGenerator::allocateFinallyRegisters):
2095         (JSC::BytecodeGenerator::releaseFinallyRegisters):
2096         (JSC::BytecodeGenerator::emitCompareFinallyActionAndJumpIf):
2097         (JSC::BytecodeGenerator::pushIteratorCloseControlFlowScope): Deleted.
2098         (JSC::BytecodeGenerator::popIteratorCloseControlFlowScope): Deleted.
2099         (JSC::BytecodeGenerator::emitComplexPopScopes): Deleted.
2100         (JSC::BytecodeGenerator::emitPopScopes): Deleted.
2101         (JSC::BytecodeGenerator::popTryAndEmitCatch): Deleted.
2102         * bytecompiler/BytecodeGenerator.h:
2103         (JSC::FinallyJump::FinallyJump):
2104         (JSC::FinallyContext::FinallyContext):
2105         (JSC::FinallyContext::outerContext):
2106         (JSC::FinallyContext::finallyLabel):
2107         (JSC::FinallyContext::depth):
2108         (JSC::FinallyContext::numberOfBreaksOrContinues):
2109         (JSC::FinallyContext::incNumberOfBreaksOrContinues):
2110         (JSC::FinallyContext::handlesReturns):
2111         (JSC::FinallyContext::setHandlesReturns):
2112         (JSC::FinallyContext::registerJump):
2113         (JSC::FinallyContext::numberOfJumps):
2114         (JSC::FinallyContext::jumps):
2115         (JSC::ControlFlowScope::ControlFlowScope):
2116         (JSC::ControlFlowScope::isLabelScope):
2117         (JSC::ControlFlowScope::isFinallyScope):
2118         (JSC::BytecodeGenerator::currentLexicalScopeIndex):
2119         (JSC::BytecodeGenerator::FinallyRegistersScope::FinallyRegistersScope):
2120         (JSC::BytecodeGenerator::FinallyRegistersScope::~FinallyRegistersScope):
2121         (JSC::BytecodeGenerator::finallyActionRegister):
2122         (JSC::BytecodeGenerator::finallyReturnValueRegister):
2123         (JSC::BytecodeGenerator::emitSetFinallyActionToNormalCompletion):
2124         (JSC::BytecodeGenerator::emitSetFinallyActionToReturnCompletion):
2125         (JSC::BytecodeGenerator::emitSetFinallyActionToJumpID):
2126         (JSC::BytecodeGenerator::emitSetFinallyReturnValueRegister):
2127         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNormalCompletion):
2128         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotJump):
2129         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsReturnCompletion):
2130         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotReturnCompletion):
2131         (JSC::BytecodeGenerator::emitJumpIfFinallyActionIsNotThrowCompletion):
2132         (JSC::BytecodeGenerator::emitJumpIfCompletionTypeIsThrow):
2133         (JSC::BytecodeGenerator::bytecodeOffsetToJumpID):
2134         (JSC::BytecodeGenerator::isInFinallyBlock): Deleted.
2135         * bytecompiler/NodesCodegen.cpp:
2136         (JSC::ContinueNode::emitBytecode):
2137         (JSC::BreakNode::emitBytecode):
2138         (JSC::ReturnNode::emitBytecode):
2139         (JSC::TryNode::emitBytecode):
2140
2141 2016-12-16  Keith Miller  <keith_miller@apple.com>
2142
2143         Add missing cases to parseUnreachableExpression and cleanup FunctionParser
2144         https://bugs.webkit.org/show_bug.cgi?id=165966
2145
2146         Reviewed by Saam Barati.
2147
2148         This patch adds a number of missing cases to the Wasm FunctionParser's unreachable
2149         code decoder. It also, removes unneeded OpType namespaces where they were not
2150         needed and has the unary / binary macros cover all the cases rather than
2151         just the simple cases.
2152
2153         * wasm/WasmFunctionParser.h:
2154
2155 2016-12-16  Mark Lam  <mark.lam@apple.com>
2156
2157         Add predecessor info to dumps from JSC_dumpBytecodeLivenessResults=true.
2158         https://bugs.webkit.org/show_bug.cgi?id=165958
2159
2160         Reviewed by Saam Barati.
2161
2162         Also:
2163         1. refactored the code to use a common lambda function to dump FastBitVectors.
2164         2. list successors by their block index instead of pointers.
2165
2166         * bytecode/BytecodeLivenessAnalysis.cpp:
2167         (JSC::BytecodeLivenessAnalysis::dumpResults):
2168
2169 2016-12-16  Saam Barati  <sbarati@apple.com>
2170
2171         WebAssembly: WasmB3IRGenerator should throw exceptions instead of crash
2172         https://bugs.webkit.org/show_bug.cgi?id=165834
2173
2174         Reviewed by Keith Miller.
2175
2176         This patch generalizes how we throw exceptions in the Wasm::B3IRGenerator.
2177         There are still places where we need to throw exceptions and we don't, but
2178         this patch removes most of those places inside the IR generator. There are
2179         still a few places we need to throw exceptions inside the IR generator, like
2180         div/mod by 0. Those will be done in a separate patch. Also, there are
2181         still some stubs we need to throw exceptions from; those will also be
2182         done in a separate patch.
2183
2184         All exceptions thrown from Wasm share a common stub. The ABI for the stub
2185         is to move the Wasm::ExceptionType into argGPR1 and jump to the stub.
2186         The stub will then throw an exception with an error message tailored
2187         to the particular Wasm::ExceptionType failure.
2188
2189         This patch also refactors B3::Compilation. Before, B3::Compilation(VM, Procedure)
2190         constructor would compile a B3 function. This patch makes B3::Compilation a simple 
2191         tuple that keeps the necessary bits of B3 function alive in order to be runnable.
2192         There is a new function that actually does the compilation for you. It is:
2193         Compilation B3::compile(VM&, Procedure&)
2194         The reason for this change is that I'm now using B3::Compilation(CodeRef, OpaqueByproducts)
2195         constructor in Wasm code. It is weird to have a class both have a
2196         constructor that instantiates the tuple, and another that performs the
2197         compilation and then instantiates the tuple. It's more straight
2198         forward if Compilation's job wasn't to actually do the compilation
2199         but just to hold the necessary bits to keep a compiled B3 alive.
2200
2201         * CMakeLists.txt:
2202         * JavaScriptCore.xcodeproj/project.pbxproj:
2203         * b3/B3Compilation.cpp:
2204         (JSC::B3::Compilation::Compilation):
2205         * b3/B3Compilation.h:
2206         * b3/B3Compile.cpp: Added.
2207         (JSC::B3::compile):
2208         * b3/B3Compile.h: Added.
2209         * b3/testb3.cpp:
2210         (JSC::B3::compile):
2211         * jit/ThunkGenerators.cpp:
2212         (JSC::throwExceptionFromWasmThunkGenerator):
2213         * jit/ThunkGenerators.h:
2214         * wasm/WasmB3IRGenerator.cpp:
2215         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2216         (JSC::Wasm::B3IRGenerator::emitExceptionCheck):
2217         (JSC::Wasm::createJSToWasmWrapper):
2218         (JSC::Wasm::parseAndCompile):
2219         * wasm/WasmExceptionType.h: Added.
2220         (JSC::Wasm::errorMessageForExceptionType):
2221
2222 2016-12-16  Keith Miller  <keith_miller@apple.com>
2223
2224         i64.eqz should use an Int64 zero
2225         https://bugs.webkit.org/show_bug.cgi?id=165942
2226
2227         Reviewed by Mark Lam.
2228
2229         This patch fixes i64.eqz, which was using an Int32 zero
2230         for the comparison previously. This patch also, adds
2231         printing opcodes names in verbose mode.
2232
2233         * wasm/WasmFunctionParser.h:
2234         * wasm/generateWasmOpsHeader.py:
2235         * wasm/wasm.json:
2236
2237 2016-12-15  Darin Adler  <darin@apple.com>
2238
2239         Use asString instead of toWTFString, toString, or getString when we already checked isString
2240         https://bugs.webkit.org/show_bug.cgi?id=165895
2241
2242         Reviewed by Yusuke Suzuki.
2243
2244         Once we have called isString, we should always use asString and value rather than using
2245         functions that have to deal with non-JSString objects. This leads to slightly fewer branches,
2246         slightly less reference count churn, since the string is stored right inside the JSString,
2247         and obviates the need for exception handling.
2248
2249         * bindings/ScriptValue.cpp:
2250         (Inspector::jsToInspectorValue): Use asString/value instead of getString.
2251         * dfg/DFGOperations.cpp:
2252         (JSC::DFG::operationMapHash): Call jsMapHash with its new arguments.
2253         * inspector/JSInjectedScriptHost.cpp:
2254         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension): Use asString/value instead
2255         of toWTFString.
2256         * inspector/JSJavaScriptCallFrame.cpp:
2257         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension): Ditto.
2258         * inspector/agents/InspectorHeapAgent.cpp:
2259         (Inspector::InspectorHeapAgent::getPreview): Use asString/tryGetValue, instead of the
2260         peculiar getString(nullptr) that was here before.
2261         * jsc.cpp:
2262         (functionGetGetterSetter): Use asString/toIdentifier instead of the much less efficient
2263         toWTFString/Identifier::fromString.
2264         (functionIsRope): Use asString instead of jsCast<JSString*>; same thing, but we should
2265         prefer the asString function, since it exists.
2266         (functionFindTypeForExpression): Use asString/value instead of getString.
2267         (functionHasBasicBlockExecuted): Ditto.
2268         (functionBasicBlockExecutionCount): Ditto.
2269         (functionCreateBuiltin): Use asString/value instead of toWTFString and removed
2270         unneeded RETURN_IF_EXCEPTION.
2271         (valueWithTypeOfWasmValue): Use asString instead of jsCast<String*>.
2272         (box): Ditto.
2273         * runtime/DateConstructor.cpp:
2274         (JSC::constructDate): Use asString/values instead of getString.
2275         * runtime/ExceptionHelpers.cpp:
2276         (JSC::errorDescriptionForValue): Tweaked formatting.
2277
2278         * runtime/HashMapImpl.h:
2279         (JSC::jsMapHash): Changed this function to use asString/value.
2280
2281         * runtime/JSCJSValue.cpp:
2282         (JSC::JSValue::dumpInContextAssumingStructure): Use asString instead of
2283         jsCast<JSString*>.
2284         (JSC::JSValue::dumpForBacktrace): Ditto.
2285         * runtime/JSCJSValueInlines.h:
2286         (JSC::toPreferredPrimitiveType): Ditto.
2287
2288         * runtime/JSGlobalObjectFunctions.cpp:
2289         (JSC::globalFuncEval): Use asString/value instead of toWTFString.
2290
2291         * runtime/JSString.cpp:
2292         (JSC::JSString::destroy): Streamlined by removing local variable.
2293         (JSC::JSString::estimatedSize): Use asString instead of jsCast<JSString*>.
2294         (JSC::JSString::visitChildren): Ditto.
2295         (JSC::JSString::toThis): Ditto.
2296         * runtime/JSString.h:
2297         (JSC::JSValue::toString): Ditto.
2298         (JSC::JSValue::toStringOrNull): Ditto.
2299         * runtime/NumberPrototype.cpp:
2300         (JSC::numberProtoFuncValueOf): Ditto.
2301         * runtime/ObjectPrototype.cpp:
2302         (JSC::objectProtoFuncToString): Ditto.
2303         * runtime/StringPrototype.cpp:
2304         (JSC::stringProtoFuncRepeatCharacter): Ditto.
2305         (JSC::stringProtoFuncSubstr): Ditto.
2306         (JSC::builtinStringSubstrInternal): Simplified assertion by removing local variable.
2307
2308 2016-12-15  Keith Miller  <keith_miller@apple.com>
2309
2310         Fix validation of non-void if blocks with no else
2311         https://bugs.webkit.org/show_bug.cgi?id=165938
2312
2313         Reviewed by Saam Barati.
2314
2315         We should not have been allowing non-void if-blocks that don't
2316         have an else. Since this causes a value to be placed on the
2317         stack that only appears under some control flow and not another.
2318
2319         * wasm/WasmValidate.cpp:
2320
2321 2016-12-15  Filip Pizlo  <fpizlo@apple.com>
2322
2323         Get rid of HeapRootVisitor and make SlotVisitor less painful to use
2324         https://bugs.webkit.org/show_bug.cgi?id=165911
2325
2326         Reviewed by Geoffrey Garen.
2327         
2328         Previously we had two ways of adding a raw pointer to the GC's mark stack:
2329         
2330         - SlotVisitor::appendUnbarrieredXYZ() methods
2331         - HeapRootVisitor::visit() methods
2332         
2333         HeapRootVisitor existed only to prevent you from calling its non-WriteBarrier<> methods
2334         unless you had permission. But SlotVisitor would let you do it anyway, because that was
2335         a lot more practical.
2336         
2337         I think that we should just have one way to do it. This removes HeapRootVisitor. It
2338         also renames appendUnbarrieredXYZ to appendUnbarriered, and it removes the use of extra
2339         indirection (so you now pass const WriteBarrier<>& instead of WriteBarrier<>*).
2340
2341         * API/JSCallbackObject.h:
2342         (JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
2343         * JavaScriptCore.xcodeproj/project.pbxproj:
2344         * Scripts/builtins/builtins_templates.py:
2345         * bytecode/CodeBlock.cpp:
2346         (JSC::CodeBlock::visitWeakly):
2347         (JSC::CodeBlock::visitChildren):
2348         (JSC::CodeBlock::propagateTransitions):
2349         (JSC::CodeBlock::determineLiveness):
2350         (JSC::CodeBlock::visitOSRExitTargets):
2351         (JSC::CodeBlock::stronglyVisitStrongReferences):
2352         (JSC::CodeBlock::stronglyVisitWeakReferences):
2353         * bytecode/DirectEvalCodeCache.cpp:
2354         (JSC::DirectEvalCodeCache::visitAggregate):
2355         * bytecode/InternalFunctionAllocationProfile.h:
2356         (JSC::InternalFunctionAllocationProfile::visitAggregate):
2357         * bytecode/ObjectAllocationProfile.h:
2358         (JSC::ObjectAllocationProfile::visitAggregate):
2359         * bytecode/PolymorphicAccess.cpp:
2360         (JSC::AccessCase::propagateTransitions):
2361         * bytecode/UnlinkedCodeBlock.cpp:
2362         (JSC::UnlinkedCodeBlock::visitChildren):
2363         * bytecode/UnlinkedFunctionExecutable.cpp:
2364         (JSC::UnlinkedFunctionExecutable::visitChildren):
2365         * debugger/DebuggerScope.cpp:
2366         (JSC::DebuggerScope::visitChildren):
2367         * dfg/DFGDesiredTransitions.cpp:
2368         (JSC::DFG::DesiredTransition::visitChildren):
2369         * dfg/DFGDesiredWeakReferences.cpp:
2370         (JSC::DFG::DesiredWeakReferences::visitChildren):
2371         * dfg/DFGGraph.cpp:
2372         (JSC::DFG::Graph::visitChildren):
2373         * dfg/DFGPlan.cpp:
2374         (JSC::DFG::Plan::markCodeBlocks):
2375         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
2376         * heap/HandleSet.cpp:
2377         (JSC::HandleSet::visitStrongHandles):
2378         * heap/HandleSet.h:
2379         * heap/HandleStack.cpp:
2380         (JSC::HandleStack::visit):
2381         * heap/HandleStack.h:
2382         * heap/Heap.cpp:
2383         (JSC::Heap::markToFixpoint):
2384         * heap/Heap.h:
2385         * heap/HeapRootVisitor.h: Removed.
2386         * heap/LargeAllocation.cpp:
2387         (JSC::LargeAllocation::visitWeakSet):
2388         * heap/LargeAllocation.h:
2389         * heap/MarkedBlock.h:
2390         (JSC::MarkedBlock::Handle::visitWeakSet):
2391         * heap/MarkedSpace.cpp:
2392         (JSC::MarkedSpace::visitWeakSets):
2393         * heap/MarkedSpace.h:
2394         * heap/SlotVisitor.cpp:
2395         (JSC::SlotVisitor::appendUnbarriered):
2396         * heap/SlotVisitor.h:
2397         * heap/SlotVisitorInlines.h:
2398         (JSC::SlotVisitor::appendUnbarriered):
2399         (JSC::SlotVisitor::append):
2400         (JSC::SlotVisitor::appendHidden):
2401         (JSC::SlotVisitor::appendValues):
2402         (JSC::SlotVisitor::appendValuesHidden):
2403         (JSC::SlotVisitor::appendUnbarrieredPointer): Deleted.
2404         (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer): Deleted.
2405         (JSC::SlotVisitor::appendUnbarrieredValue): Deleted.
2406         (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Deleted.
2407         (JSC::SlotVisitor::appendUnbarrieredWeak): Deleted.
2408         * heap/WeakBlock.cpp:
2409         (JSC::WeakBlock::specializedVisit):
2410         (JSC::WeakBlock::visit):
2411         * heap/WeakBlock.h:
2412         * heap/WeakSet.h:
2413         (JSC::WeakSet::visit):
2414         * interpreter/ShadowChicken.cpp:
2415         (JSC::ShadowChicken::visitChildren):
2416         * jit/GCAwareJITStubRoutine.cpp:
2417         (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
2418         * jit/PolymorphicCallStubRoutine.cpp:
2419         (JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
2420         * jsc.cpp:
2421         (WTF::Element::visitChildren):
2422         (WTF::ImpureGetter::visitChildren):
2423         (WTF::SimpleObject::visitChildren):
2424         * runtime/AbstractModuleRecord.cpp:
2425         (JSC::AbstractModuleRecord::visitChildren):
2426         * runtime/ArgList.cpp:
2427         (JSC::MarkedArgumentBuffer::markLists):
2428         * runtime/ArgList.h:
2429         * runtime/ClonedArguments.cpp:
2430         (JSC::ClonedArguments::visitChildren):
2431         * runtime/DirectArguments.cpp:
2432         (JSC::DirectArguments::visitChildren):
2433         * runtime/EvalExecutable.cpp:
2434         (JSC::EvalExecutable::visitChildren):
2435         * runtime/Exception.cpp:
2436         (JSC::Exception::visitChildren):
2437         * runtime/FunctionExecutable.cpp:
2438         (JSC::FunctionExecutable::visitChildren):
2439         * runtime/FunctionRareData.cpp:
2440         (JSC::FunctionRareData::visitChildren):
2441         * runtime/GetterSetter.cpp:
2442         (JSC::GetterSetter::visitChildren):
2443         * runtime/HashMapImpl.cpp:
2444         (JSC::HashMapBucket<Data>::visitChildren):
2445         (JSC::HashMapImpl<HashMapBucket>::visitChildren):
2446         * runtime/InferredTypeTable.cpp:
2447         (JSC::InferredTypeTable::visitChildren):
2448         * runtime/InternalFunction.cpp:
2449         (JSC::InternalFunction::visitChildren):
2450         * runtime/IntlCollator.cpp:
2451         (JSC::IntlCollator::visitChildren):
2452         * runtime/IntlCollatorConstructor.cpp:
2453         (JSC::IntlCollatorConstructor::visitChildren):
2454         * runtime/IntlDateTimeFormat.cpp:
2455         (JSC::IntlDateTimeFormat::visitChildren):
2456         * runtime/IntlDateTimeFormatConstructor.cpp:
2457         (JSC::IntlDateTimeFormatConstructor::visitChildren):
2458         * runtime/IntlNumberFormat.cpp:
2459         (JSC::IntlNumberFormat::visitChildren):
2460         * runtime/IntlNumberFormatConstructor.cpp:
2461         (JSC::IntlNumberFormatConstructor::visitChildren):
2462         * runtime/JSBoundFunction.cpp:
2463         (JSC::JSBoundFunction::visitChildren):
2464         * runtime/JSCallee.cpp:
2465         (JSC::JSCallee::visitChildren):
2466         * runtime/JSCellInlines.h:
2467         (JSC::JSCell::visitChildren):
2468         * runtime/JSCustomGetterSetterFunction.cpp:
2469         (JSC::JSCustomGetterSetterFunction::visitChildren):
2470         * runtime/JSFunction.cpp:
2471         (JSC::JSFunction::visitChildren):
2472         * runtime/JSGlobalObject.cpp:
2473         (JSC::JSGlobalObject::visitChildren):
2474         * runtime/JSMapIterator.cpp:
2475         (JSC::JSMapIterator::visitChildren):
2476         * runtime/JSModuleEnvironment.cpp:
2477         (JSC::JSModuleEnvironment::visitChildren):
2478         * runtime/JSModuleNamespaceObject.cpp:
2479         (JSC::JSModuleNamespaceObject::visitChildren):
2480         * runtime/JSModuleRecord.cpp:
2481         (JSC::JSModuleRecord::visitChildren):
2482         * runtime/JSNativeStdFunction.cpp:
2483         (JSC::JSNativeStdFunction::visitChildren):
2484         * runtime/JSObject.cpp:
2485         (JSC::JSObject::visitButterflyImpl):
2486         * runtime/JSPromiseDeferred.cpp:
2487         (JSC::JSPromiseDeferred::visitChildren):
2488         * runtime/JSPropertyNameEnumerator.cpp:
2489         (JSC::JSPropertyNameEnumerator::visitChildren):
2490         * runtime/JSPropertyNameIterator.cpp:
2491         (JSC::JSPropertyNameIterator::visitChildren):
2492         * runtime/JSProxy.cpp:
2493         (JSC::JSProxy::visitChildren):
2494         * runtime/JSScope.cpp:
2495         (JSC::JSScope::visitChildren):
2496         * runtime/JSSegmentedVariableObject.cpp:
2497         (JSC::JSSegmentedVariableObject::visitChildren):
2498         * runtime/JSSetIterator.cpp:
2499         (JSC::JSSetIterator::visitChildren):
2500         * runtime/JSString.cpp:
2501         (JSC::JSRopeString::visitFibers):
2502         * runtime/JSSymbolTableObject.cpp:
2503         (JSC::JSSymbolTableObject::visitChildren):
2504         * runtime/JSWeakMap.cpp:
2505         (JSC::JSWeakMap::visitChildren):
2506         * runtime/JSWeakSet.cpp:
2507         (JSC::JSWeakSet::visitChildren):
2508         * runtime/JSWithScope.cpp:
2509         (JSC::JSWithScope::visitChildren):
2510         * runtime/JSWrapperObject.cpp:
2511         (JSC::JSWrapperObject::visitChildren):
2512         * runtime/LazyClassStructure.cpp:
2513         (JSC::LazyClassStructure::visit):
2514         * runtime/LazyPropertyInlines.h:
2515         (JSC::ElementType>::visit):
2516         * runtime/MapBase.cpp:
2517         (JSC::MapBase<HashMapBucketType>::visitChildren):
2518         * runtime/ModuleProgramExecutable.cpp:
2519         (JSC::ModuleProgramExecutable::visitChildren):
2520         * runtime/NativeErrorConstructor.cpp:
2521         (JSC::NativeErrorConstructor::visitChildren):
2522         * runtime/ProgramExecutable.cpp:
2523         (JSC::ProgramExecutable::visitChildren):
2524         * runtime/ProxyObject.cpp:
2525         (JSC::ProxyObject::visitChildren):
2526         * runtime/ProxyRevoke.cpp:
2527         (JSC::ProxyRevoke::visitChildren):
2528         * runtime/RegExpCachedResult.cpp:
2529         (JSC::RegExpCachedResult::visitChildren):
2530         * runtime/RegExpObject.cpp:
2531         (JSC::RegExpObject::visitChildren):
2532         * runtime/RegExpPrototype.cpp:
2533         (JSC::RegExpPrototype::visitChildren):
2534         * runtime/SamplingProfiler.cpp:
2535         (JSC::SamplingProfiler::visit):
2536         * runtime/ScopedArguments.cpp:
2537         (JSC::ScopedArguments::visitChildren):
2538         * runtime/SmallStrings.cpp:
2539         (JSC::SmallStrings::visitStrongReferences):
2540         * runtime/SparseArrayValueMap.cpp:
2541         (JSC::SparseArrayValueMap::visitChildren):
2542         * runtime/Structure.cpp:
2543         (JSC::Structure::visitChildren):
2544         (JSC::Structure::markIfCheap):
2545         * runtime/StructureChain.cpp:
2546         (JSC::StructureChain::visitChildren):
2547         * runtime/StructureRareData.cpp:
2548         (JSC::StructureRareData::visitChildren):
2549         * runtime/SymbolTable.cpp:
2550         (JSC::SymbolTable::visitChildren):
2551         * runtime/TypeProfilerLog.cpp:
2552         (JSC::TypeProfilerLog::visit):
2553         * runtime/WeakMapData.cpp:
2554         (JSC::WeakMapData::DeadKeyCleaner::visitWeakReferences):
2555         * wasm/js/JSWebAssemblyInstance.cpp:
2556         (JSC::JSWebAssemblyInstance::visitChildren):
2557         * wasm/js/JSWebAssemblyMemory.cpp:
2558         (JSC::JSWebAssemblyMemory::visitChildren):
2559         * wasm/js/JSWebAssemblyModule.cpp:
2560         (JSC::JSWebAssemblyModule::visitChildren):
2561         * wasm/js/JSWebAssemblyTable.cpp:
2562         (JSC::JSWebAssemblyTable::visitChildren):
2563         * wasm/js/WebAssemblyFunction.cpp:
2564         (JSC::WebAssemblyFunction::visitChildren):
2565         * wasm/js/WebAssemblyModuleRecord.cpp:
2566         (JSC::WebAssemblyModuleRecord::visitChildren):
2567
2568 2016-12-15  Myles C. Maxfield  <mmaxfield@apple.com>
2569
2570         Sort Xcode project files
2571         https://bugs.webkit.org/show_bug.cgi?id=165937
2572
2573         Reviewed by Simon Fraser.
2574
2575         * JavaScriptCore.xcodeproj/project.pbxproj:
2576
2577 2016-12-15  Keith Miller  <keith_miller@apple.com>
2578
2579         Wasm should not create empty unlinked callsites
2580         https://bugs.webkit.org/show_bug.cgi?id=165933
2581
2582         Reviewed by Mark Lam.
2583
2584         Wasm would create holes in the unlinked callsite vector if B3 was able to
2585         eliminate the callsite.
2586
2587         * wasm/WasmB3IRGenerator.cpp:
2588         (JSC::Wasm::B3IRGenerator::addCall):
2589
2590 2016-12-15  JF Bastien  <jfbastien@apple.com>
2591
2592         WebAssembly: improve compilation error messages
2593         https://bugs.webkit.org/show_bug.cgi?id=163919
2594
2595         Reviewed by Saam Barati.
2596
2597         The error handling messages were underwhelming because most
2598         locations merely returned `false` on failure. This patch uses
2599         std::expected to denote that failure isn't expected. Doing this
2600         makes it almost impossible to mess up the code: either a function
2601         returns a result (or a partial result for internal helpers) or an
2602         error. We're not synchronizing the error string with the m_failed
2603         bool anymore, and the caller will abort if they try to get a
2604         result but the outcome was an error.
2605
2606         This also shortens the code significantly using macros, while also
2607         judiciously preventing inlining of error handling code and biasing
2608         towards success using UNLIKELY. This means that the generated code
2609         should be more efficient (no string formatting on success, and
2610         regalloc can avoid these unlikely paths).
2611
2612         The patch adds a few missing checks as well, especially related to
2613         count limits and memory allocation failure.
2614
2615         As a follow-up I'd like to improve WTF::makeString further, so it
2616         does coercions to string and understands ADL as I did in this
2617         patch.
2618
2619         * wasm/WasmB3IRGenerator.cpp:
2620         (JSC::Wasm::B3IRGenerator::fail):
2621         (JSC::Wasm::parseAndCompile):
2622         * wasm/WasmB3IRGenerator.h:
2623         * wasm/WasmFormat.h:
2624         (JSC::Wasm::isValidExternalKind):
2625         (JSC::Wasm::makeString):
2626         * wasm/WasmFunctionParser.h:
2627         * wasm/WasmModuleParser.cpp:
2628         * wasm/WasmModuleParser.h:
2629         * wasm/WasmParser.h:
2630         (JSC::Wasm::FailureHelper::makeString):
2631         (JSC::Wasm::Parser::fail):
2632         (JSC::Wasm::Parser<SuccessType>::Parser):
2633         (JSC::Wasm::Parser<SuccessType>::consumeCharacter):
2634         (JSC::Wasm::Parser<SuccessType>::consumeString):
2635         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
2636         (JSC::Wasm::Parser<SuccessType>::parseVarUInt32):
2637         (JSC::Wasm::Parser<SuccessType>::parseVarUInt64):
2638         (JSC::Wasm::Parser<SuccessType>::parseVarInt32):
2639         (JSC::Wasm::Parser<SuccessType>::parseVarInt64):
2640         (JSC::Wasm::Parser<SuccessType>::parseUInt32):
2641         (JSC::Wasm::Parser<SuccessType>::parseUInt64):
2642         (JSC::Wasm::Parser<SuccessType>::parseUInt8):
2643         (JSC::Wasm::Parser<SuccessType>::parseInt7):
2644         (JSC::Wasm::Parser<SuccessType>::parseUInt7):
2645         (JSC::Wasm::Parser<SuccessType>::parseVarUInt1):
2646         (JSC::Wasm::Parser<SuccessType>::parseResultType):
2647         (JSC::Wasm::Parser<SuccessType>::parseValueType):
2648         (JSC::Wasm::Parser<SuccessType>::parseExternalKind):
2649         * wasm/WasmPlan.cpp:
2650         (JSC::Wasm::Plan::run):
2651         * wasm/WasmSections.h:
2652         (JSC::Wasm::isValidSection):
2653         (JSC::Wasm::validateOrder):
2654         (JSC::Wasm::makeString):
2655         * wasm/WasmValidate.cpp:
2656         (JSC::Wasm::Validate::fail):
2657         (JSC::Wasm::Validate::addUnreachable):
2658         (JSC::Wasm::validateFunction):
2659         * wasm/WasmValidate.h:
2660         * wasm/generateWasmB3IRGeneratorInlinesHeader.py:
2661         * wasm/generateWasmOpsHeader.py:
2662         * wasm/generateWasmValidateInlinesHeader.py:
2663         (loadMacro):
2664         (storeMacro):
2665         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2666         (JSC::constructJSWebAssemblyInstance):
2667         * wasm/js/WebAssemblyModuleRecord.cpp:
2668         (JSC::WebAssemblyModuleRecord::link):
2669
2670 2016-12-15  JF Bastien  <jfbastien@apple.com>
2671
2672         WebAssembly API: improve data section errors, initialize after Element
2673         https://bugs.webkit.org/show_bug.cgi?id=165733
2674
2675         Reviewed by Keith Miller.
2676
2677         * wasm/WasmModuleParser.cpp:
2678         (JSC::Wasm::ModuleParser::parseData): Data section without Memory section or import is a validation error
2679         * wasm/js/WebAssemblyModuleRecord.cpp:
2680         (JSC::dataSegmentFail):
2681         (JSC::WebAssemblyModuleRecord::evaluate): tighten checks (though the spec isn't fully baked), and move after Element initialization
2682
2683 2016-12-15  Keith Miller  <keith_miller@apple.com>
2684
2685         Turn on WebAssembly by default
2686         https://bugs.webkit.org/show_bug.cgi?id=165918
2687
2688         Reviewed by Saam Barati.
2689
2690         * runtime/Options.h:
2691
2692 2016-12-15  Konstantin Tokarev  <annulen@yandex.ru>
2693
2694         Added missing override and final specifiers
2695         https://bugs.webkit.org/show_bug.cgi?id=165903
2696
2697         Reviewed by Darin Adler.
2698
2699         * bytecompiler/BytecodeGenerator.h:
2700         * jsc.cpp:
2701         * parser/Nodes.h:
2702
2703 2016-12-15  Chris Dumez  <cdumez@apple.com>
2704
2705         Harden JSObject::getOwnPropertyDescriptor()
2706         https://bugs.webkit.org/show_bug.cgi?id=165908
2707
2708         Reviewed by Geoffrey Garen.
2709
2710         * runtime/JSObject.cpp:
2711         (JSC::JSObject::getOwnPropertyDescriptor):
2712
2713 2016-12-15  Keith Miller  <keith_miller@apple.com>
2714
2715         Fix 64-bit shift family Wasm opcodes
2716         https://bugs.webkit.org/show_bug.cgi?id=165902
2717
2718         Reviewed by Geoffrey Garen.
2719
2720         The Int64 versions of the shift family B3 opcodes take an Int32
2721         for the shift value. Wasm, however, takes an i64, so we need to
2722         Trunc the shift value. Also, this fixes a bug where shr_u mapped
2723         to signed shift and shr_s mapped to the unsigned shift.
2724
2725         * wasm/wasm.json:
2726
2727 2016-12-14  Keith Miller  <keith_miller@apple.com>
2728
2729         Wasm should decode constants correctly
2730         https://bugs.webkit.org/show_bug.cgi?id=165886
2731
2732         Reviewed by Saam Barati.
2733
2734         This patch fixes how we decode the constant part of i32, i64, f32,
2735         and f64.const opcodes.
2736
2737         * wasm/WasmFunctionParser.h:
2738         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2739         * wasm/wasm.json:
2740
2741 2016-12-14  Saam Barati  <sbarati@apple.com>
2742
2743         WebAssembly: Add various low hanging fruit that will allow us to run the LLVM torture tests in Wasm
2744         https://bugs.webkit.org/show_bug.cgi?id=165883
2745
2746         Reviewed by Keith Miller.
2747
2748         This patch implements some low hanging fruit:
2749         - Exporting Table
2750         - Exporting Memory
2751         - Load16 with zero extension to both 32 and 64 bit values.
2752         - Fixes Unreachable to emit code that will prevent B3 from having a validation error.
2753
2754         * wasm/WasmB3IRGenerator.cpp:
2755         (JSC::Wasm::B3IRGenerator::addUnreachable):
2756         (JSC::Wasm::sizeOfLoadOp):
2757         (JSC::Wasm::B3IRGenerator::emitLoadOp):
2758         * wasm/WasmFunctionParser.h:
2759         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2760         * wasm/WasmModuleParser.cpp:
2761         (JSC::Wasm::ModuleParser::parseExport):
2762         * wasm/WasmValidate.cpp:
2763         (JSC::Wasm::Validate::addUnreachable):
2764         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2765         (JSC::constructJSWebAssemblyInstance):
2766         * wasm/js/WebAssemblyModuleRecord.cpp:
2767         (JSC::WebAssemblyModuleRecord::finishCreation):
2768         (JSC::WebAssemblyModuleRecord::link):
2769
2770 2016-12-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2771
2772         Update ModuleLoader code by using the latest builtin primitives
2773         https://bugs.webkit.org/show_bug.cgi?id=165851
2774
2775         Reviewed by Sam Weinig.
2776
2777         Update the module loader code,
2778
2779         1. Use @globalPrivate for the utilities, instead of setting them as the member of ModuleLoader.
2780         2. Use @putByValDirect instead of @push. @push is user-observable since it uses Set() operation
2781            and it can be observed by defining indexed setters in Array.prototype.
2782
2783         * builtins/ModuleLoaderPrototype.js:
2784         (ensureRegistered):
2785         (fulfillFetch):
2786         (commitInstantiated):
2787         (requestFetch):
2788         (requestSatisfy):
2789         (setStateToMax): Deleted.
2790         (newRegistryEntry): Deleted.
2791         * runtime/ModuleLoaderPrototype.cpp:
2792
2793 2016-12-14  Michael Saboff  <msaboff@apple.com>
2794
2795         The stress GC bot crashes in JavaScriptCore beneath ShadowChicken::update and Inspector::jsToInspectorValue
2796         https://bugs.webkit.org/show_bug.cgi?id=165871
2797
2798         Reviewed by Mark Lam.
2799
2800         This fixes two issues with the VM watch dog timer firing in a worker.
2801
2802         The first issue has to do with bytecode ordering.  Prior to this change, the first few opcodes
2803         generated when the watch dog is enabled are:
2804                 op_enter
2805                 op_watchdog
2806                 op_get_scope
2807         When the watchdog fires, the function will get an exception at op_watchdog.  In processing that exception,
2808         we'll try to update the ShadowChicken shadow stack.  That update assumes that if there is a scope 
2809         VirtualRegister allocated, then the slot contains a valid JSScope.  With the current bytecode ordering,
2810         this is not true at op_watchdog as op_enter will put JSUndefined in the scope slot.  It isn't until the
2811         op_get_scope gets processed that we'll have a valid scope in the slot.  The fix for this issue is to 
2812         ensure that op_get_scope happens before the op_watchdog.
2813
2814         The second issue is that ScriptFunctionCall::call() will not tell its caller that a terminated
2815         execution exception happened.  Instead call() returns an empty JSValue.  InjectedScript::wrapCallFrames()
2816         wasn't checking for an empty JSValue, but was passing it to another function.  Added a short circuit
2817         return when call returns an empty JSValue.
2818
2819         Added <https://bugs.webkit.org/show_bug.cgi?id=165875> to fix other callers of ScriptFunctionCall::call()
2820         to check for an empty JSValue return value.
2821         Also tracked with <rdar://problem/29671015>.
2822
2823         * bytecompiler/BytecodeGenerator.cpp:
2824         (JSC::BytecodeGenerator::BytecodeGenerator):
2825         (JSC::BytecodeGenerator::emitEnter):
2826         * inspector/InjectedScript.cpp:
2827         (Inspector::InjectedScript::wrapCallFrames):
2828
2829 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2830
2831         DirectTailCall implementation needs to tell the shuffler what to put into the ArgumentCount explicitly
2832         https://bugs.webkit.org/show_bug.cgi?id=165882
2833
2834         Reviewed by Mark Lam.
2835         
2836         The CallFrameShuffler was assuming that the ArgumentCount that it should store into the
2837         callee frame is simply the size of the args vector.
2838         
2839         That's not true for DirectTailCall, which will pad the args vector with undefined if we
2840         are optimizing an arity mismatch. We need to pass the ArgumentCount explicitly in this
2841         case.
2842
2843         * dfg/DFGSpeculativeJIT32_64.cpp:
2844         (JSC::DFG::SpeculativeJIT::emitCall):
2845         * dfg/DFGSpeculativeJIT64.cpp:
2846         (JSC::DFG::SpeculativeJIT::emitCall):
2847         * ftl/FTLLowerDFGToB3.cpp:
2848         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
2849         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
2850         * jit/CallFrameShuffleData.h:
2851         * jit/CallFrameShuffler.cpp:
2852         (JSC::CallFrameShuffler::CallFrameShuffler):
2853         (JSC::CallFrameShuffler::prepareAny):
2854         * jit/CallFrameShuffler.h:
2855         (JSC::CallFrameShuffler::snapshot):
2856         * jit/JITCall.cpp:
2857         (JSC::JIT::compileOpCall):
2858
2859 2016-12-14  Keith Miller  <keith_miller@apple.com>
2860
2861         WebAssembly JS API: implement Global
2862         https://bugs.webkit.org/show_bug.cgi?id=164133
2863
2864         Reviewed by Saam Barati.
2865
2866         This patch adds support for globals. It handles imports, exports
2867         and internal globals. In the MVP only internal globals are allowed
2868         to be mutable. This means we can store a C-array of 64-bit slots
2869         off the instance holding them. When globals are exported to JS
2870         they are done so as numbers. This means that i64 globals cannot be
2871         imported or exported.
2872
2873         * wasm/WasmB3IRGenerator.cpp:
2874         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2875         (JSC::Wasm::B3IRGenerator::getGlobal):
2876         (JSC::Wasm::B3IRGenerator::setGlobal):
2877         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2878         (JSC::Wasm::parseAndCompile):
2879         * wasm/WasmFormat.h:
2880         * wasm/WasmFunctionParser.h:
2881         (JSC::Wasm::FunctionParser<Context>::parseExpression):
2882         * wasm/WasmModuleParser.cpp:
2883         (JSC::Wasm::ModuleParser::parseImport):
2884         (JSC::Wasm::ModuleParser::parseGlobal):
2885         (JSC::Wasm::ModuleParser::parseExport):
2886         (JSC::Wasm::ModuleParser::parseElement):
2887         (JSC::Wasm::ModuleParser::parseInitExpr):
2888         (JSC::Wasm::ModuleParser::parseGlobalType):
2889         (JSC::Wasm::ModuleParser::parseData):
2890         * wasm/WasmModuleParser.h:
2891         * wasm/WasmParser.h:
2892         (JSC::Wasm::Parser::parseVarInt32):
2893         (JSC::Wasm::Parser::parseVarInt64):
2894         (JSC::Wasm::Parser::parseUInt64):
2895         * wasm/WasmValidate.cpp:
2896         (JSC::Wasm::Validate::hasMemory):
2897         (JSC::Wasm::Validate::Validate):
2898         (JSC::Wasm::Validate::getGlobal):
2899         (JSC::Wasm::Validate::setGlobal):
2900         (JSC::Wasm::validateFunction):
2901         * wasm/generateWasmOpsHeader.py:
2902         * wasm/js/JSWebAssemblyInstance.cpp:
2903         (JSC::JSWebAssemblyInstance::create):
2904         (JSC::JSWebAssemblyInstance::finishCreation):
2905         (JSC::JSWebAssemblyInstance::visitChildren):
2906         * wasm/js/JSWebAssemblyInstance.h:
2907         (JSC::JSWebAssemblyInstance::loadI32Global):
2908         (JSC::JSWebAssemblyInstance::loadI64Global):
2909         (JSC::JSWebAssemblyInstance::loadF32Global):
2910         (JSC::JSWebAssemblyInstance::loadF64Global):
2911         (JSC::JSWebAssemblyInstance::setGlobal):
2912         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
2913         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2914         (JSC::constructJSWebAssemblyInstance):
2915         * wasm/js/WebAssemblyModuleRecord.cpp:
2916         (JSC::WebAssemblyModuleRecord::finishCreation):
2917         (JSC::WebAssemblyModuleRecord::link):
2918
2919 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2920
2921         Unreviewed, re-enable concurrent GC on ARM64 now that the most likely culprit of the memory
2922         regressions is fixed. Lets see what the bots think!
2923
2924         * runtime/Options.cpp:
2925         (JSC::recomputeDependentOptions):
2926
2927 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
2928
2929         Devices with fewer cores should use a more aggressive GC schedule by default
2930         https://bugs.webkit.org/show_bug.cgi?id=165859
2931
2932         Reviewed by Mark Lam.
2933
2934         * heap/Heap.cpp:
2935         (JSC::Heap::markToFixpoint): Log when we have an unexpected delay in wake-up.
2936         * heap/SlotVisitor.cpp:
2937         (JSC::SlotVisitor::drainInParallelPassively): Don't drain passively if there aren't many cores.
2938         * runtime/Options.cpp:
2939         (JSC::overrideDefaults): Change the heuristics if we have fewer cores.
2940         (JSC::Options::initialize):
2941         * runtime/Options.h:
2942
2943 2016-12-14  Mark Lam  <mark.lam@apple.com>
2944
2945         BytecodeBasicBlock::computeImpl() should not keep iterating blocks if all jump targets have already been found.
2946         https://bugs.webkit.org/show_bug.cgi?id=165820
2947
2948         Reviewed by Saam Barati.
2949
2950         Currently, if an opcode is a branch type opcode, BytecodeBasicBlock::computeImpl()
2951         will iterate over all basic blocks looking for the block containing the jump
2952         target, and it will continue to do this even when all the jump targets have been
2953         found.  This is wasted work, and all the more so given that most branch type
2954         opcodes only have a single jump target.
2955
2956         * bytecode/BytecodeBasicBlock.cpp:
2957         (JSC::BytecodeBasicBlock::computeImpl):
2958
2959 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
2960
2961         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
2962         https://bugs.webkit.org/show_bug.cgi?id=165741
2963
2964         Unreviewed, re-landing this with fix (revert erroneous change to Options).
2965
2966         * CMakeLists.txt:
2967         * JavaScriptCore.xcodeproj/project.pbxproj:
2968         * heap/CellContainer.cpp: Added.
2969         (JSC::CellContainer::isNewlyAllocated):
2970         * heap/CellContainer.h:
2971         * heap/MarkedAllocator.cpp:
2972         (JSC::MarkedAllocator::addBlock):
2973         (JSC::MarkedAllocator::removeBlock):
2974         (JSC::MarkedAllocator::dumpBits):
2975         * heap/MarkedAllocator.h:
2976         (JSC::MarkedAllocator::forEachBitVector):
2977         (JSC::MarkedAllocator::forEachBitVectorWithName):
2978         * heap/MarkedBlock.cpp:
2979         (JSC::MarkedBlock::tryCreate):
2980         (JSC::MarkedBlock::Handle::~Handle):
2981         (JSC::MarkedBlock::MarkedBlock):
2982         (JSC::MarkedBlock::Handle::specializedSweep):
2983         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
2984         (JSC::MarkedBlock::Handle::stopAllocating):
2985         (JSC::MarkedBlock::Handle::resumeAllocating):
2986         (JSC::MarkedBlock::aboutToMarkSlow):
2987         (JSC::MarkedBlock::Handle::didConsumeFreeList):
2988         (JSC::MarkedBlock::Handle::dumpState):
2989         * heap/MarkedBlock.h:
2990         (JSC::MarkedBlock::markingVersion):
2991         (JSC::MarkedBlock::isMarkedRaw):
2992         (JSC::MarkedBlock::isMarked):
2993         * heap/MarkedBlockInlines.h:
2994         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
2995         * heap/SlotVisitor.cpp:
2996         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
2997         * runtime/StructureIDTable.h:
2998         (JSC::StructureIDTable::size):
2999         (JSC::StructureIDTable::get):
3000
3001 2016-12-14  Chris Dumez  <cdumez@apple.com>
3002
3003         Unreviewed, rolling out r209766.
3004
3005         Regressed Dromaeo JSLib by ~50%
3006
3007         Reverted changeset:
3008
3009         "Make opaque root scanning truly constraint-based"
3010         https://bugs.webkit.org/show_bug.cgi?id=165760
3011         http://trac.webkit.org/changeset/209766
3012
3013 2016-12-14  Commit Queue  <commit-queue@webkit.org>
3014
3015         Unreviewed, rolling out r209795.
3016         https://bugs.webkit.org/show_bug.cgi?id=165853
3017
3018         rolled out the wrong revision (Requested by pizlo on #webkit).
3019
3020         Reverted changeset:
3021
3022         "MarkedBlock::marksConveyLivenessDuringMarking should take
3023         into account collection scope"
3024         https://bugs.webkit.org/show_bug.cgi?id=165741
3025         http://trac.webkit.org/changeset/209795
3026
3027 2016-12-14  Filip Pizlo  <fpizlo@apple.com>
3028
3029         Unreviewed, disable concurrent GC on ARM while we investigate a memory use regression.
3030
3031         * runtime/Options.cpp:
3032         (JSC::recomputeDependentOptions):
3033
3034 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3035
3036         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
3037         https://bugs.webkit.org/show_bug.cgi?id=165795
3038
3039         Reviewed by Saam Barati.
3040
3041         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
3042         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
3043         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
3044         allocations.
3045
3046         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
3047
3048         * API/JSValueRef.cpp:
3049         (JSValueToStringCopy):
3050         * bindings/ScriptValue.cpp:
3051         (Deprecated::ScriptValue::toString):
3052         * inspector/JSGlobalObjectInspectorController.cpp:
3053         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
3054         * inspector/JSInjectedScriptHost.cpp:
3055         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3056         * inspector/JSJavaScriptCallFrame.cpp:
3057         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3058         * inspector/ScriptCallStackFactory.cpp:
3059         (Inspector::extractSourceInformationFromException):
3060         * runtime/ConsoleObject.cpp:
3061         (JSC::valueToStringWithUndefinedOrNullCheck):
3062         (JSC::valueOrDefaultLabelString):
3063         * runtime/DateConstructor.cpp:
3064         (JSC::dateParse):
3065         * runtime/DatePrototype.cpp:
3066         (JSC::formatLocaleDate):
3067         * runtime/ErrorInstance.cpp:
3068         (JSC::ErrorInstance::sanitizedToString):
3069         * runtime/ErrorPrototype.cpp:
3070         (JSC::errorProtoFuncToString):
3071         * runtime/InspectorInstrumentationObject.cpp:
3072         (JSC::inspectorInstrumentationObjectLog):
3073         * runtime/JSGlobalObjectFunctions.cpp:
3074         (JSC::globalFuncEval):
3075         * runtime/JSModuleLoader.cpp:
3076         (JSC::JSModuleLoader::fetch):
3077         * runtime/ModuleLoaderPrototype.cpp:
3078         (JSC::moduleLoaderPrototypeParseModule):
3079         * runtime/RegExpConstructor.cpp:
3080         (JSC::regExpCreate):
3081         * runtime/RegExpPrototype.cpp:
3082         (JSC::regExpProtoFuncCompile):
3083         (JSC::regExpProtoFuncToString):
3084         * runtime/StringPrototype.cpp:
3085         (JSC::replaceUsingRegExpSearch):
3086         (JSC::replaceUsingStringSearch):
3087         (JSC::stringProtoFuncSlice):
3088         (JSC::stringProtoFuncSplitFast):
3089         (JSC::stringProtoFuncSubstr):
3090         (JSC::stringProtoFuncLocaleCompare):
3091         (JSC::stringProtoFuncBig):
3092         (JSC::stringProtoFuncSmall):
3093         (JSC::stringProtoFuncBlink):
3094         (JSC::stringProtoFuncBold):
3095         (JSC::stringProtoFuncFixed):
3096         (JSC::stringProtoFuncItalics):
3097         (JSC::stringProtoFuncStrike):
3098         (JSC::stringProtoFuncSub):
3099         (JSC::stringProtoFuncSup):
3100         (JSC::stringProtoFuncFontcolor):
3101         (JSC::stringProtoFuncFontsize):
3102         (JSC::stringProtoFuncAnchor):
3103         (JSC::stringProtoFuncLink):
3104         (JSC::trimString):
3105         (JSC::stringProtoFuncStartsWith):
3106         (JSC::stringProtoFuncEndsWith):
3107         (JSC::stringProtoFuncIncludes):
3108         (JSC::builtinStringIncludesInternal):
3109         (JSC::stringProtoFuncNormalize):
3110         * tools/JSDollarVMPrototype.cpp:
3111         (JSC::functionPrint):
3112         * wasm/js/JSWebAssemblyCompileError.h:
3113         (JSC::JSWebAssemblyCompileError::create):
3114         * wasm/js/JSWebAssemblyRuntimeError.h:
3115         (JSC::JSWebAssemblyRuntimeError::create):
3116
3117 2016-12-14  Gavin Barraclough  <barraclough@apple.com>
3118
3119         MarkedBlock::marksConveyLivenessDuringMarking should take into account collection scope
3120         https://bugs.webkit.org/show_bug.cgi?id=165741
3121
3122         Unreviewed rollout due to performance regression.
3123
3124         * CMakeLists.txt:
3125         * JavaScriptCore.xcodeproj/project.pbxproj:
3126         * heap/CellContainer.cpp: Removed.
3127         * heap/CellContainer.h:
3128         * heap/MarkedAllocator.cpp:
3129         (JSC::MarkedAllocator::addBlock):
3130         (JSC::MarkedAllocator::removeBlock):
3131         (JSC::MarkedAllocator::dumpBits):
3132         * heap/MarkedAllocator.h:
3133         (JSC::MarkedAllocator::forEachBitVector):
3134         (JSC::MarkedAllocator::forEachBitVectorWithName):
3135         * heap/MarkedBlock.cpp:
3136         (JSC::MarkedBlock::tryCreate):
3137         (JSC::MarkedBlock::Handle::~Handle):
3138         (JSC::MarkedBlock::MarkedBlock):
3139         (JSC::MarkedBlock::Handle::specializedSweep):
3140         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
3141         (JSC::MarkedBlock::Handle::stopAllocating):
3142         (JSC::MarkedBlock::Handle::resumeAllocating):
3143         (JSC::MarkedBlock::aboutToMarkSlow):
3144         (JSC::MarkedBlock::Handle::didConsumeFreeList):
3145         (JSC::MarkedBlock::Handle::dumpState): Deleted.
3146         * heap/MarkedBlock.h:
3147         (JSC::MarkedBlock::isMarked):
3148         (JSC::MarkedBlock::markingVersion): Deleted.
3149         (JSC::MarkedBlock::isMarkedRaw): Deleted.
3150         * heap/MarkedBlockInlines.h:
3151         (JSC::MarkedBlock::marksConveyLivenessDuringMarking):
3152         * heap/SlotVisitor.cpp:
3153         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
3154         * runtime/Options.h:
3155         * runtime/StructureIDTable.h:
3156         (JSC::StructureIDTable::get):
3157         (JSC::StructureIDTable::size): Deleted.
3158
3159 2016-12-13  Commit Queue  <commit-queue@webkit.org>
3160
3161         Unreviewed, rolling out r209792.
3162         https://bugs.webkit.org/show_bug.cgi?id=165841
3163
3164         Cause build failures (Requested by yusukesuzuki on #webkit).
3165
3166         Reverted changeset:
3167
3168         "Use JSValue::toWTFString instead of calling toString(exec)
3169         and value(exec)"
3170         https://bugs.webkit.org/show_bug.cgi?id=165795
3171         http://trac.webkit.org/changeset/209792
3172
3173 2016-12-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3174
3175         Use JSValue::toWTFString instead of calling toString(exec) and value(exec)
3176         https://bugs.webkit.org/show_bug.cgi?id=165795
3177
3178         Reviewed by Saam Barati.
3179
3180         In old days, we frequently use the idiom like, `value.toString(exec)->value(exec)` to
3181         get WTFString from the given JSValue. But now, we have better function, `toWTFString`.
3182         `toWTFString` does not create intermediate JSString objects, then reduce unnecessary
3183         allocations.
3184
3185         This patch mechanically replaces `value.toString(exec)->value(exec)` with `toWTFString(exec)`.
3186
3187         * API/JSValueRef.cpp:
3188         (JSValueToStringCopy):
3189         * bindings/ScriptValue.cpp:
3190         (Deprecated::ScriptValue::toString):
3191         * inspector/JSGlobalObjectInspectorController.cpp:
3192         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
3193         * inspector/JSInjectedScriptHost.cpp:
3194         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3195         * inspector/JSJavaScriptCallFrame.cpp:
3196         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3197         * inspector/ScriptCallStackFactory.cpp:
3198         (Inspector::extractSourceInformationFromException):
3199         * runtime/ConsoleObject.cpp:
3200         (JSC::valueToStringWithUndefinedOrNullCheck):
3201         (JSC::valueOrDefaultLabelString):
3202         * runtime/DateConstructor.cpp:
3203         (JSC::dateParse):
3204         * runtime/DatePrototype.cpp:
3205         (JSC::formatLocaleDate):
3206         * runtime/ErrorInstance.cpp:
3207         (JSC::ErrorInstance::sanitizedToString):
3208         * runtime/ErrorPrototype.cpp:
3209         (JSC::errorProtoFuncToString):
3210         * runtime/InspectorInstrumentationObject.cpp:
3211         (JSC::inspectorInstrumentationObjectLog):
3212         * runtime/JSCJSValue.cpp:
3213         (JSC::JSValue::toWTFStringSlowCase):
3214         * runtime/JSGlobalObjectFunctions.cpp:
3215         (JSC::globalFuncEval):
3216         * runtime/JSModuleLoader.cpp:
3217         (JSC::JSModuleLoader::fetch):
3218         * runtime/ModuleLoaderPrototype.cpp:
3219         (JSC::moduleLoaderPrototypeParseModule):
3220         * runtime/RegExpConstructor.cpp:
3221         (JSC::regExpCreate):
3222         * runtime/RegExpPrototype.cpp:
3223         (JSC::regExpProtoFuncCompile):
3224         (JSC::regExpProtoFuncToString):
3225         * runtime/StringPrototype.cpp:
3226         (JSC::replaceUsingRegExpSearch):
3227         (JSC::replaceUsingStringSearch):
3228         (JSC::stringProtoFuncSlice):
3229         (JSC::stringProtoFuncSplitFast):
3230         (JSC::stringProtoFuncSubstr):
3231         (JSC::stringProtoFuncLocaleCompare):
3232         (JSC::stringProtoFuncBig):
3233         (JSC::stringProtoFuncSmall):
3234         (JSC::stringProtoFuncBlink):
3235         (JSC::stringProtoFuncBold):
3236         (JSC::stringProtoFuncFixed):
3237         (JSC::stringProtoFuncItalics):
3238         (JSC::stringProtoFuncStrike):
3239         (JSC::stringProtoFuncSub):
3240         (JSC::stringProtoFuncSup):
3241         (JSC::stringProtoFuncFontcolor):
3242         (JSC::stringProtoFuncFontsize):
3243         (JSC::stringProtoFuncAnchor):
3244         (JSC::stringProtoFuncLink):
3245         (JSC::trimString):
3246         (JSC::stringProtoFuncStartsWith):
3247         (JSC::stringProtoFuncEndsWith):
3248         (JSC::stringProtoFuncIncludes):
3249         (JSC::builtinStringIncludesInternal):
3250         (JSC::stringProtoFuncNormalize):
3251         * tools/JSDollarVMPrototype.cpp:
3252         (JSC::functionPrint):
3253         * wasm/js/JSWebAssemblyCompileError.h:
3254         (JSC::JSWebAssemblyCompileError::create):
3255         * wasm/js/JSWebAssemblyRuntimeError.h:
3256         (JSC::JSWebAssemblyRuntimeError::create):
3257
3258 2016-12-13  Saam Barati  <sbarati@apple.com>
3259
3260         WebAssembly: implement the elements section
3261         https://bugs.webkit.org/show_bug.cgi?id=165715
3262
3263         Reviewed by Keith Miller.
3264
3265         This is a straight forward implementation of the Element
3266         section in the Wasm spec:
3267         https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#element-section
3268         
3269         There are a few ambiguities I encountered when implementing this, so I've
3270         filed bugs against the Wasm design repo, and corresponding bugzilla bugs
3271         for us to address after they've been discussed by the various Wasm folks:
3272         - https://bugs.webkit.org/show_bug.cgi?id=165827
3273         - https://bugs.webkit.org/show_bug.cgi?id=165826
3274         - https://bugs.webkit.org/show_bug.cgi?id=165825
3275
3276         * wasm/WasmFormat.h:
3277         * wasm/WasmModuleParser.cpp:
3278         (JSC::Wasm::ModuleParser::parseElement):
3279         (JSC::Wasm::ModuleParser::parseInitExpr):
3280         (JSC::Wasm::ModuleParser::parseData):
3281         * wasm/WasmModuleParser.h:
3282         * wasm/js/WebAssemblyModuleRecord.cpp:
3283         (JSC::WebAssemblyModuleRecord::evaluate):
3284
3285 2016-12-13  Chris Dumez  <cdumez@apple.com>
3286
3287         Unreviewed, rolling out r209544.
3288
3289         Looks like r209489 did not cause the performance regression
3290         after all
3291
3292         Reverted changeset:
3293
3294         "Unreviewed, rolling out r209489."
3295         https://bugs.webkit.org/show_bug.cgi?id=165550
3296         http://trac.webkit.org/changeset/209544
3297
3298 2016-12-13  Saam Barati  <sbarati@apple.com>
3299
3300         WebAssembly: implement the table section and table import
3301         https://bugs.webkit.org/show_bug.cgi?id=165716
3302
3303         Reviewed by Keith Miller.
3304
3305         This patch implements the Table space for wasm:
3306         https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md#table-section
3307
3308         It only implements defining and importing a table. The bulk
3309         of this patch is implementing the various wasm Table prototype
3310         methods and the underlying Table object:
3311         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblytable-constructor
3312
3313         This patch also fixes a bug in our implementation with call_indirect.