Implement linear memory instructions in WebAssembly
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2
3         Implement linear memory instructions in WebAssembly
4         https://bugs.webkit.org/show_bug.cgi?id=149326
5
6         Reviewed by Geoffrey Garen.
7
8         This patch implements linear memory instructions in WebAssembly.[1] To
9         use the linear memory, an ArrayBuffer must be passed to loadWebAssembly().
10
11         Notes:
12         - We limit the ArrayBuffer's byte length to 2^31 - 1. This enables us to
13           use only one comparison (unsigned greater than) to check for
14           out-of-bounds access.
15         - There is no consensus yet on what should happen when an out-of-bounds
16           access occurs.[2] For now, we throw an error when that happens.
17         - In asm.js, a heap access looks like this: int32Array[i >> 2]. Note
18           that ">> 2" is part of the syntax and is required. pack-asmjs will
19           produce bytecodes that look something like "LoadI32, i" (not
20           "LoadI32, ShiftRightI32, i, 2"). The requirement of the shift operator
21           prevents unaligned accesses in asm.js. (There is a proposal to support
22           unaligned accesses in the future version of asm.js using DataView.[3])
23           The WebAssembly spec allows unaligned accesses.[4] But since we use
24           asm.js for testing, we follow asm.js's behaviors for now.
25
26         [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#linear-memory
27         [2]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#out-of-bounds
28         [3]: https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Possible_asm.js_extensions_that_don.27t_require_new_JS_features
29         [4]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#alignment
30
31         * jit/JITOperations.cpp:
32         * jit/JITOperations.h:
33         * jsc.cpp:
34         (GlobalObject::finishCreation):
35         (functionLoadWebAssembly):
36         * tests/stress/wasm-linear-memory.js: Added.
37         (shouldBe):
38         (shouldThrow):
39         * tests/stress/wasm/linear-memory.wasm: Added.
40         * wasm/JSWASMModule.cpp:
41         (JSC::JSWASMModule::JSWASMModule):
42         (JSC::JSWASMModule::visitChildren):
43         * wasm/JSWASMModule.h:
44         (JSC::JSWASMModule::create):
45         (JSC::JSWASMModule::arrayBuffer):
46         (JSC::JSWASMModule::JSWASMModule): Deleted.
47         * wasm/WASMConstants.h:
48         * wasm/WASMFunctionCompiler.h:
49         (JSC::sizeOfMemoryType):
50         (JSC::WASMFunctionCompiler::MemoryAddress::MemoryAddress):
51         (JSC::WASMFunctionCompiler::endFunction):
52         (JSC::WASMFunctionCompiler::buildLoad):
53         (JSC::WASMFunctionCompiler::buildStore):
54         * wasm/WASMFunctionParser.cpp:
55         (JSC::WASMFunctionParser::parseStatement):
56         (JSC::WASMFunctionParser::parseExpressionI32):
57         (JSC::WASMFunctionParser::parseExpressionF32):
58         (JSC::WASMFunctionParser::parseExpressionF64):
59         (JSC::WASMFunctionParser::parseMemoryAddress):
60         (JSC::WASMFunctionParser::parseLoad):
61         (JSC::WASMFunctionParser::parseStore):
62         * wasm/WASMFunctionParser.h:
63         * wasm/WASMFunctionSyntaxChecker.h:
64         (JSC::WASMFunctionSyntaxChecker::MemoryAddress::MemoryAddress):
65         (JSC::WASMFunctionSyntaxChecker::buildLoad):
66         (JSC::WASMFunctionSyntaxChecker::buildStore):
67         * wasm/WASMModuleParser.cpp:
68         (JSC::WASMModuleParser::WASMModuleParser):
69         (JSC::WASMModuleParser::parseModule):
70         (JSC::parseWebAssembly):
71         (JSC::WASMModuleParser::parse): Deleted.
72         * wasm/WASMModuleParser.h:
73
74 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
75
76         Implement type conversion instructions in WebAssembly
77         https://bugs.webkit.org/show_bug.cgi?id=149340
78
79         Reviewed by Mark Lam.
80
81         This patch implements some type conversion instructions in WebAssembly.
82         The WebAssembly spec has a lot more type conversion instructions than
83         what are available in asm.js.[1] We only implement the ones that are in
84         asm.js for now because we can only test those.
85
86         [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md
87
88         * tests/stress/wasm-type-conversion.js:
89         * tests/stress/wasm/type-conversion.wasm:
90         * wasm/WASMConstants.h:
91         * wasm/WASMFunctionCompiler.h:
92         (JSC::operationConvertUnsignedInt32ToDouble):
93         (JSC::WASMFunctionCompiler::buildConvertType):
94         (JSC::WASMFunctionCompiler::callOperation):
95         * wasm/WASMFunctionParser.cpp:
96         (JSC::WASMFunctionParser::parseExpressionI32):
97         (JSC::WASMFunctionParser::parseExpressionF32):
98         (JSC::WASMFunctionParser::parseExpressionF64):
99         (JSC::WASMFunctionParser::parseConvertType):
100         * wasm/WASMFunctionParser.h:
101         * wasm/WASMFunctionSyntaxChecker.h:
102         (JSC::WASMFunctionSyntaxChecker::buildConvertType):
103
104 2015-09-18  Alex Christensen  <achristensen@webkit.org>
105
106         Fix tests on Windows after switching to CMake.
107         https://bugs.webkit.org/show_bug.cgi?id=149339
108
109         Reviewed by Brent Fulgham.
110
111         * shell/PlatformWin.cmake:
112         Build testapi and testRegExp (which doesn't seem to be used any more).
113
114 2015-09-17  Brian Burg  <bburg@apple.com>
115
116         ASSERT(!m_frontendRouter->hasLocalFrontend()) when running Web Inspector tests
117         https://bugs.webkit.org/show_bug.cgi?id=149006
118
119         Reviewed by Joseph Pecoraro.
120
121         Prior to disconnecting, we need to know how many frontends remain connected.
122
123         * inspector/InspectorFrontendRouter.h: Add frontendCount().
124
125 2015-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
126
127         Explicitly specify builtin JS files dependency
128         https://bugs.webkit.org/show_bug.cgi?id=149323
129
130         Reviewed by Alex Christensen.
131
132         JSCBuiltins.{h,cpp} in CMakeLists.txt and DerivedSources.make just depend on the builtins directory.
133         As a result, even if we modify builtins/*.js code, regenerating JSCBuiltins.{h,cpp} does not occur.
134         As the same to the cpp sources, let's list up the JS files explicitly.
135
136         * CMakeLists.txt:
137         * DerivedSources.make:
138
139 2015-09-18  Michael Saboff  <msaboff@apple.com>
140
141         Remove register preservation and restoration stub code
142         https://bugs.webkit.org/show_bug.cgi?id=149335
143
144         Reviewed by Mark Lam.
145
146         Delete the register preservation and restoration thunks and related plumbing.
147
148         Much of this change is removing the unneeded RegisterPreservationMode parameter
149         from various functions.
150
151         * CMakeLists.txt:
152         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
153         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
154         * JavaScriptCore.xcodeproj/project.pbxproj:
155         * bytecode/CallLinkInfo.h:
156         (JSC::CallLinkInfo::isVarargsCallType):
157         (JSC::CallLinkInfo::CallLinkInfo):
158         (JSC::CallLinkInfo::isVarargs):
159         (JSC::CallLinkInfo::isLinked):
160         (JSC::CallLinkInfo::setUpCallFromFTL):
161         (JSC::CallLinkInfo::registerPreservationMode): Deleted.
162         * ftl/FTLJITCode.cpp:
163         (JSC::FTL::JITCode::initializeAddressForCall):
164         (JSC::FTL::JITCode::addressForCall):
165         * ftl/FTLJITCode.h:
166         * ftl/FTLOSREntry.cpp:
167         (JSC::FTL::prepareOSREntry):
168         * ftl/FTLOSRExitCompiler.cpp:
169         (JSC::FTL::compileStub):
170         * jit/JITCode.cpp:
171         (JSC::JITCode::execute):
172         (JSC::DirectJITCode::initializeCodeRef):
173         (JSC::DirectJITCode::addressForCall):
174         (JSC::NativeJITCode::initializeCodeRef):
175         (JSC::NativeJITCode::addressForCall):
176         (JSC::DirectJITCode::ensureWrappers): Deleted.
177         * jit/JITCode.h:
178         (JSC::JITCode::jitTypeFor):
179         (JSC::JITCode::executableAddress):
180         * jit/JITOperations.cpp:
181         * jit/RegisterPreservationWrapperGenerator.cpp: Removed.
182         * jit/RegisterPreservationWrapperGenerator.h: Removed.
183         * jit/Repatch.cpp:
184         (JSC::linkPolymorphicCall):
185         * jit/ThunkGenerators.cpp:
186         (JSC::virtualThunkFor):
187         * jit/ThunkGenerators.h:
188         * llint/LLIntSlowPaths.cpp:
189         (JSC::LLInt::entryOSR):
190         (JSC::LLInt::setUpCall):
191         * runtime/Executable.cpp:
192         (JSC::ExecutableBase::clearCode):
193         (JSC::ScriptExecutable::installCode):
194         (JSC::WebAssemblyExecutable::prepareForExecution):
195         * runtime/Executable.h:
196         (JSC::ExecutableBase::generatedJITCodeFor):
197         (JSC::ExecutableBase::entrypointFor):
198         (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
199         * runtime/RegisterPreservationMode.h: Removed.
200
201 2015-09-17  Joseph Pecoraro  <pecoraro@apple.com>
202
203         Web Inspector: Remove unused canClearBrowserCookies / canClearBrowserCache protocol methods
204         https://bugs.webkit.org/show_bug.cgi?id=149307
205
206         Reviewed by Brian Burg.
207
208         * inspector/protocol/Network.json:
209         Remove unused protocol methods.
210
211 2015-09-17  Commit Queue  <commit-queue@webkit.org>
212
213         Unreviewed, rolling out r189938, r189952, and r189956.
214         https://bugs.webkit.org/show_bug.cgi?id=149329
215
216         Broke Web Workers (Requested by ap on #webkit).
217
218         Reverted changesets:
219
220         "Implement try/catch in the DFG."
221         https://bugs.webkit.org/show_bug.cgi?id=147374
222         http://trac.webkit.org/changeset/189938
223
224         "CLoop build fix after r189938."
225         http://trac.webkit.org/changeset/189952
226
227         "add a regress test for richards with try/catch."
228         https://bugs.webkit.org/show_bug.cgi?id=149301
229         http://trac.webkit.org/changeset/189956
230
231 2015-09-17  Ryosuke Niwa  <rniwa@webkit.org>
232
233         CLoop build fix after r189938.
234
235         * interpreter/StackVisitor.cpp:
236         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
237
238 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
239
240         Convert return values from JavaScript functions to the expected types in WebAssembly
241         https://bugs.webkit.org/show_bug.cgi?id=149200
242
243         Reviewed by Mark Lam.
244
245         When a WebAssembly function calls a JavaScript function, there is no
246         guarantee that the JavaScript function will always return values of the
247         type we expect. This patch converts the return values to the expected
248         types.
249
250         (The reverse is also true: When a WebAssembly function is called from a
251         JavaScript function, there is no guarantee that the arguments to the
252         WebAssembly function will always be of the types we expect. We have
253         fixed this in Bug 149033.)
254
255         We don't need to type check the return values if the callee is a
256         WebAssembly function. We don't need to type check the arguments if the
257         caller is a WebAssembly function. This optimization will be
258         implemented in the future. See https://bugs.webkit.org/show_bug.cgi?id=149310
259
260         * tests/stress/wasm-type-conversion.js:
261         * tests/stress/wasm/type-conversion.wasm:
262         * wasm/WASMFunctionCompiler.h:
263         (JSC::WASMFunctionCompiler::startFunction):
264         (JSC::WASMFunctionCompiler::buildReturn):
265         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
266         (JSC::WASMFunctionCompiler::callAndUnboxResult):
267         (JSC::WASMFunctionCompiler::convertValueToInt32):
268         (JSC::WASMFunctionCompiler::convertValueToDouble):
269         (JSC::WASMFunctionCompiler::convertDoubleToValue):
270         (JSC::WASMFunctionCompiler::loadValueAndConvertToInt32): Deleted.
271         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble): Deleted.
272         * wasm/WASMFunctionParser.cpp:
273         (JSC::WASMFunctionParser::parseExpressionI32):
274         (JSC::WASMFunctionParser::parseExpressionF32):
275         (JSC::WASMFunctionParser::parseExpressionF64):
276         (JSC::WASMFunctionParser::parseCallInternalExpressionI32): Deleted.
277         * wasm/WASMFunctionParser.h:
278
279 2015-09-17  Yusuke Suzuki  <utatane.tea@gmail.com>
280
281         [ES6] Add more fine-grained APIs and additional hooks to control module loader from WebCore
282         https://bugs.webkit.org/show_bug.cgi?id=149129
283
284         Reviewed by Saam Barati.
285
286         No behavior change.
287
288         Module tag `<script type="module>` will be executed asynchronously.
289         But we would like to fetch the resources before when the postTask-ed task is performed.
290         So instead of 1 API that fetch, instantiate and execute the module,
291         we need 2 fine-grained APIs.
292
293         1. Fetch and initialize a module, but not execute it yet.
294         2. Link and execute a module specified by the key (this will be invoked asynchronously).
295
296         And to instrument the script execution (like reporting the execution time of the module to
297         the inspector), we need a hook to inject code around an execution of a module body.
298
299         * builtins/ModuleLoaderObject.js:
300         (moduleEvaluation):
301         (loadAndEvaluateModule):
302         (loadModule):
303         (linkAndEvaluateModule):
304         * jsc.cpp:
305         (functionLoadModule):
306         (runWithScripts):
307         * runtime/Completion.cpp:
308         (JSC::identifierToJSValue):
309         (JSC::createSymbolForEntryPointModule):
310         (JSC::rejectPromise):
311         (JSC::loadAndEvaluateModule):
312         (JSC::loadModule):
313         (JSC::linkAndEvaluateModule):
314         (JSC::evaluateModule): Deleted.
315         * runtime/Completion.h:
316         * runtime/JSGlobalObject.cpp:
317         * runtime/JSGlobalObject.h:
318         * runtime/JSModuleRecord.cpp:
319         (JSC::JSModuleRecord::evaluate):
320         (JSC::JSModuleRecord::execute): Deleted.
321         * runtime/JSModuleRecord.h:
322         * runtime/ModuleLoaderObject.cpp:
323         (JSC::ModuleLoaderObject::loadAndEvaluateModule):
324         (JSC::ModuleLoaderObject::linkAndEvaluateModule):
325         (JSC::ModuleLoaderObject::evaluate):
326         (JSC::moduleLoaderObjectEvaluate):
327         * runtime/ModuleLoaderObject.h:
328
329 2015-09-17  Saam barati  <sbarati@apple.com>
330
331         Implement try/catch in the DFG.
332         https://bugs.webkit.org/show_bug.cgi?id=147374
333
334         Reviewed by Filip Pizlo.
335
336         This patch implements try/catch inside the DFG JIT.
337         It also prevents tier up to the FTL for any functions
338         that have an op_catch in them that are DFG compiled.
339
340         This patch accomplishes implementing try/catch inside
341         the DFG by OSR exiting to op_catch when an exception is thrown.
342         We can OSR exit from an exception inside the DFG in two ways:
343         1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
344         2) We have an exception when returing from a callOperation
345
346         In the case of (1), we get to the OSR exit from genericUnwind because
347         the exception was thrown in a child call frame. This means these
348         OSR exits must act as defacto op_catches (even though we will still OSR
349         exit to a baseline op_catch). That means they must restore the stack pointer
350         and call frame.
351
352         In the case of (2), we can skip genericUnwind because we know the exception 
353         check will take us to a particular OSR exit. Instead, we link these
354         exception checks as jumps to a particular OSR exit.
355
356         Both types of OSR exits will exit into op_catch inside the baseline JIT.
357         Because they exit to op_catch, these OSR exits must set callFrameForCatch
358         to the proper call frame pointer.
359
360         We "handle" all exceptions inside the machine frame of the DFG code
361         block. This means the machine code block is responsible for "catching"
362         exceptions of any inlined frames' try/catch. OSR exit will then exit to 
363         the proper baseline CodeBlock after reifying the inlined frames
364         (DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to). 
365         Also, genericUnwind will never consult an inlined call frame's CodeBlock to 
366         see if they can catch the exception because they can't. We always unwind to the 
367         next machine code block frame. The DFG CodeBlock changes how the exception 
368         handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks. 
369
370         So, when consulting call sites that throw, we keep track of the CallSiteIndex,
371         and the HandlerInfo for the corresponding baseline exception handler for
372         that particular CallSiteIndex (if an exception at that call site will be caught). 
373         Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
374         inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
375         (The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
376         at from genericUnwind).
377
378         Also, each OSR exit will know if it acting as an exception handler, and
379         whether or not it will be arrived at from genericUnwind. When we know we 
380         will arrive at an OSR exit from genericUnwind, we set the corresponding 
381         HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.
382
383         This patch also introduces a new Phase inside the DFG that ensures
384         that DFG CodeBlocks that handle exceptions take the necessary
385         steps to keep live variables at "op_catch" live according the
386         OSR exit value recovery machinery. We accomplish this by flushing
387         all live op_catch variables to the stack when inside a "try" block.
388
389         * CMakeLists.txt:
390         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
391         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
392         * JavaScriptCore.xcodeproj/project.pbxproj:
393         * bytecode/CodeBlock.cpp:
394         (JSC::CodeBlock::handlerForBytecodeOffset):
395         (JSC::CodeBlock::handlerForIndex):
396         * bytecode/CodeBlock.h:
397         (JSC::CodeBlock::clearExceptionHandlers):
398         (JSC::CodeBlock::appendExceptionHandler):
399         * bytecode/PreciseJumpTargets.cpp:
400         (JSC::computePreciseJumpTargets):
401         * dfg/DFGByteCodeParser.cpp:
402         (JSC::DFG::ByteCodeParser::getLocal):
403         (JSC::DFG::ByteCodeParser::setLocal):
404         (JSC::DFG::ByteCodeParser::parseBlock):
405         * dfg/DFGCapabilities.cpp:
406         (JSC::DFG::capabilityLevel):
407         * dfg/DFGCommonData.cpp:
408         (JSC::DFG::CommonData::addCodeOrigin):
409         (JSC::DFG::CommonData::lastCallSite):
410         (JSC::DFG::CommonData::shrinkToFit):
411         * dfg/DFGCommonData.h:
412         * dfg/DFGGraph.h:
413         * dfg/DFGJITCompiler.cpp:
414         (JSC::DFG::JITCompiler::linkOSRExits):
415         (JSC::DFG::JITCompiler::link):
416         (JSC::DFG::JITCompiler::compile):
417         (JSC::DFG::JITCompiler::noticeOSREntry):
418         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
419         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
420         (JSC::DFG::JITCompiler::exceptionCheck):
421         (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
422         * dfg/DFGJITCompiler.h:
423         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
424         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
425         (JSC::DFG::JITCompiler::appendCall):
426         (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
427         (JSC::DFG::JITCompiler::blockHeads):
428         (JSC::DFG::JITCompiler::exceptionCheck): Deleted.
429         * dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
430         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
431         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
432         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
433         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
434         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
435         (JSC::DFG::performLiveCatchVariablePreservationPhase):
436         * dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
437         * dfg/DFGOSRExit.cpp:
438         (JSC::DFG::OSRExit::OSRExit):
439         (JSC::DFG::OSRExit::setPatchableCodeOffset):
440         * dfg/DFGOSRExit.h:
441         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
442         * dfg/DFGOSRExitCompiler.cpp:
443         * dfg/DFGOSRExitCompiler32_64.cpp:
444         (JSC::DFG::OSRExitCompiler::compileExit):
445         * dfg/DFGOSRExitCompiler64.cpp:
446         (JSC::DFG::OSRExitCompiler::compileExit):
447         * dfg/DFGOSRExitCompilerCommon.cpp:
448         (JSC::DFG::osrWriteBarrier):
449         (JSC::DFG::adjustAndJumpToTarget):
450         * dfg/DFGOSRExitCompilerCommon.h:
451         * dfg/DFGPlan.cpp:
452         (JSC::DFG::Plan::compileInThreadImpl):
453         * dfg/DFGSlowPathGenerator.h:
454         (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
455         (JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
456         (JSC::DFG::SlowPathGenerator::generate):
457         * dfg/DFGSpeculativeJIT.h:
458         * dfg/DFGSpeculativeJIT32_64.cpp:
459         (JSC::DFG::SpeculativeJIT::cachedGetById):
460         (JSC::DFG::SpeculativeJIT::cachedPutById):
461         (JSC::DFG::SpeculativeJIT::emitCall):
462         * dfg/DFGSpeculativeJIT64.cpp:
463         (JSC::DFG::SpeculativeJIT::cachedGetById):
464         (JSC::DFG::SpeculativeJIT::cachedPutById):
465         (JSC::DFG::SpeculativeJIT::emitCall):
466         * dfg/DFGTierUpCheckInjectionPhase.cpp:
467         (JSC::DFG::TierUpCheckInjectionPhase::run):
468         * ftl/FTLOSRExitCompiler.cpp:
469         (JSC::FTL::compileStub):
470         * interpreter/Interpreter.cpp:
471         (JSC::GetCatchHandlerFunctor::operator()):
472         (JSC::UnwindFunctor::operator()):
473         * interpreter/StackVisitor.cpp:
474         (JSC::StackVisitor::gotoNextFrame):
475         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
476         (JSC::StackVisitor::readFrame):
477         * interpreter/StackVisitor.h:
478         (JSC::StackVisitor::operator*):
479         (JSC::StackVisitor::operator->):
480         * jit/AssemblyHelpers.cpp:
481         (JSC::AssemblyHelpers::emitExceptionCheck):
482         (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
483         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
484         * jit/AssemblyHelpers.h:
485         (JSC::AssemblyHelpers::emitCount):
486         * jit/JITExceptions.cpp:
487         (JSC::genericUnwind):
488         * jit/JITOpcodes.cpp:
489         (JSC::JIT::emit_op_catch):
490         * jit/JITOpcodes32_64.cpp:
491         (JSC::JIT::emit_op_catch):
492         * llint/LowLevelInterpreter32_64.asm:
493         * llint/LowLevelInterpreter64.asm:
494         * runtime/VM.h:
495         (JSC::VM::clearException):
496         (JSC::VM::clearLastException):
497         (JSC::VM::addressOfCallFrameForCatch):
498         (JSC::VM::exception):
499         (JSC::VM::addressOfException):
500         * tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
501         (f):
502         (bar):
503         (Foo):
504         * tests/stress/es6-for-of-loop-exception.js: Added.
505         (assert):
506         (shouldThrowInvalidConstAssignment):
507         (baz):
508         (foo):
509         * tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
510         (assert):
511         (o.valueOf):
512         (o.toString):
513         (read):
514         (bar):
515         (foo):
516         * tests/stress/exception-dfg-not-strict-equal.js: Added.
517         (foo):
518         (o.valueOf):
519         (o.toString):
520         (assert):
521         (shouldDoSomethingInFinally):
522         (catch):
523         * tests/stress/exception-dfg-operation-read-value.js: Added.
524         (assert):
525         (o.valueOf):
526         (o.toString):
527         (read):
528         (foo):
529         * tests/stress/exception-dfg-throw-from-catch-block.js: Added.
530         (assert):
531         (baz):
532         (bar):
533         (foo):
534
535 2015-09-17  Filip Pizlo  <fpizlo@apple.com>
536
537         0.0 should really be 0.0
538         https://bugs.webkit.org/show_bug.cgi?id=149283
539
540         Reviewed by Mark Lam.
541
542         A while ago (http://trac.webkit.org/changeset/180813) we introduced the idea that if the
543         user wrote a number with a decimal point (like "0.0") then we should treat that number as
544         a double. That's probably a pretty good idea. But, we ended up doing it inconsistently.
545         The DFG would indeed treat such a number as a double by consulting the
546         SourceCodeRepresentation, but the other execution engines would still see Int32:0.
547
548         This patch makes it consistent.
549
550         This is necessary for property type inference to perform well. Otherwise, a store of a
551         constant would change type from the baseline engine to the DFG, which would then cause
552         a storm of property type invalidations and recompilations.
553
554         * bytecompiler/BytecodeGenerator.cpp:
555         (JSC::BytecodeGenerator::addConstantValue):
556
557 2015-09-17  Filip Pizlo  <fpizlo@apple.com>
558
559         stress/exit-from-getter.js.ftl-eager occasionally traps in debug
560         https://bugs.webkit.org/show_bug.cgi?id=149096
561
562         Reviewed by Geoffrey Garen.
563
564         JS calls to getters/setters in get/put inline caches need to reset SP after the call, as our
565         calling convention requires.
566
567         * bytecode/PolymorphicAccess.cpp:
568         (JSC::AccessCase::generate): Fix the bug.
569         * ftl/FTLLink.cpp:
570         (JSC::FTL::link): Adds some verbiage about why the FTL stack offset logic is correct.
571         * tests/stress/getter-arity.js: Added. Other tests would flaky crash before the patch. This test instacrashes before the patch.
572
573 2015-09-17  Saam barati  <sbarati@apple.com>
574
575         Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions
576         https://bugs.webkit.org/show_bug.cgi?id=149228
577
578         Reviewed by Mark Lam.
579
580         op_catch is now responsible for filtering exceptions that
581         aren't catchable. When op_catch encounters an uncatchable
582         exception, it will call back into genericUnwind and throw
583         the exception further down the call stack. This is necessary
584         in a later patch that will implement exception handling
585         in the DFG, and part of that patch includes exception
586         handling that doesn't go through genericUnwind. The DFG try/catch
587         patch will not go through genericUnwind when it knows that
588         an exception check after a callOperation will be caught inside the 
589         machine frame or any inlined frames. This patch enables that 
590         patch by destroying the notion that all exception handling must 
591         filter through genericUnwind.
592
593         This patch maintains compatibility with the debugger and
594         profiler by ensuring we notify the debugger when an
595         exception is thrown inside VM::throwException and not
596         in genericUnwind. It also notifies the profiler that we've
597         potentially changed call frames inside op_catch.
598
599         * debugger/Debugger.cpp:
600         (JSC::Debugger::pauseIfNeeded):
601         * interpreter/Interpreter.cpp:
602         (JSC::unwindCallFrame):
603         (JSC::getStackFrameCodeType):
604         (JSC::UnwindFunctor::operator()):
605         (JSC::Interpreter::unwind):
606         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
607         (JSC::checkedReturn):
608         * interpreter/Interpreter.h:
609         (JSC::SuspendExceptionScope::SuspendExceptionScope):
610         (JSC::SuspendExceptionScope::~SuspendExceptionScope):
611         (JSC::Interpreter::sampler):
612         * jit/JIT.h:
613         * jit/JITInlines.h:
614         (JSC::JIT::callOperation):
615         (JSC::JIT::callOperationNoExceptionCheck):
616         * jit/JITOpcodes.cpp:
617         (JSC::JIT::emit_op_catch):
618         * jit/JITOpcodes32_64.cpp:
619         (JSC::JIT::emit_op_catch):
620         * jit/JITOperations.cpp:
621         * jit/JITOperations.h:
622         * llint/LLIntSlowPaths.cpp:
623         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
624         (JSC::LLInt::llint_throw_stack_overflow_error):
625         * llint/LLIntSlowPaths.h:
626         * llint/LowLevelInterpreter32_64.asm:
627         * llint/LowLevelInterpreter64.asm:
628         * runtime/ExceptionHelpers.cpp:
629         (JSC::isTerminatedExecutionException):
630         * runtime/VM.cpp:
631         (JSC::VM::throwException):
632         * runtime/VM.h:
633         (JSC::VM::targetMachinePCForThrowOffset):
634         (JSC::VM::restorePreviousException):
635         (JSC::VM::clearException):
636         (JSC::VM::clearLastException):
637         (JSC::VM::exception):
638         (JSC::VM::addressOfException):
639         (JSC::VM::setException):
640
641 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
642
643         Calling a float function on x86 in WebAssembly incorrectly returns a double
644         https://bugs.webkit.org/show_bug.cgi?id=149254
645
646         Reviewed by Michael Saboff.
647
648         In WebAssembly on x86 (32-bit), when we call a function that returns a
649         float or a double, we use the FSTP instruction to read the return value
650         from the FPU register stack. The FSTP instruction converts the value to
651         single-precision or double-precision floating-point format, depending on
652         the destination operand. Currently, we always use double as the
653         destination, which is wrong. This patch uses the correct return type.
654         This should fix the test errors in tests/stress/wasm-arithmetic-float32.js
655
656         * assembler/X86Assembler.h:
657         (JSC::X86Assembler::fstps):
658         * wasm/WASMFunctionCompiler.h:
659         (JSC::WASMFunctionCompiler::appendCallSetResult):
660         (JSC::WASMFunctionCompiler::callOperation):
661
662 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
663
664         Save and restore callee save registers in WebAssembly
665         https://bugs.webkit.org/show_bug.cgi?id=149247
666
667         Reviewed by Michael Saboff.
668
669         Save callee save registers when entering WebAssembly functions
670         and restore them when returning.
671
672         * jit/RegisterSet.cpp:
673         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
674         * jit/RegisterSet.h:
675         * wasm/WASMFunctionCompiler.h:
676         (JSC::WASMFunctionCompiler::startFunction):
677         (JSC::WASMFunctionCompiler::endFunction):
678         (JSC::WASMFunctionCompiler::buildReturn):
679         (JSC::WASMFunctionCompiler::localAddress):
680         (JSC::WASMFunctionCompiler::temporaryAddress):
681         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
682         (JSC::WASMFunctionCompiler::callAndUnboxResult):
683
684 2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>
685
686         Implement indirect calls in WebAssembly
687         https://bugs.webkit.org/show_bug.cgi?id=149100
688
689         Reviewed by Geoffrey Garen.
690
691         This patch implement indirect calls for WebAssembly files generated by
692         pack-asmjs <https://github.com/WebAssembly/polyfill-prototype-1>.
693         pack-asmjs uses the same indirect call model as asm.js. In asm.js, an
694         indirect call looks like this:
695             t[i & n](...)
696         where t is a variable referring to an array of functions with the same
697         signature, i is an integer expression, n is an integer that is equal to
698         (t.length - 1), and t.length is a power of two. pack-asmjs does not
699         use the '&' operator nor n in the WebAssembly output, but the semantics
700         is still the same as asm.js.
701
702         * tests/stress/wasm-calls.js:
703         * tests/stress/wasm/calls.wasm:
704         * wasm/WASMFormat.h:
705         * wasm/WASMFunctionCompiler.h:
706         (JSC::WASMFunctionCompiler::buildCallIndirect):
707         * wasm/WASMFunctionParser.cpp:
708         (JSC::WASMFunctionParser::parseExpressionI32):
709         (JSC::WASMFunctionParser::parseExpressionF32):
710         (JSC::WASMFunctionParser::parseExpressionF64):
711         (JSC::WASMFunctionParser::parseCallIndirect):
712         * wasm/WASMFunctionParser.h:
713         * wasm/WASMFunctionSyntaxChecker.h:
714         (JSC::WASMFunctionSyntaxChecker::buildCallIndirect):
715         * wasm/WASMModuleParser.cpp:
716         (JSC::WASMModuleParser::parseFunctionPointerTableSection):
717         (JSC::WASMModuleParser::parseFunctionDefinitionSection):
718
719 2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>
720
721         Fix 32-bit build issues in WebAssembly
722         https://bugs.webkit.org/show_bug.cgi?id=149240
723
724         Reviewed by Geoffrey Garen.
725
726         Fix the syntax error and replace the instructions that are not available on
727         64-bit platforms.
728
729         * wasm/WASMFunctionCompiler.h:
730         (JSC::WASMFunctionCompiler::startFunction):
731         (JSC::WASMFunctionCompiler::endFunction):
732         (JSC::WASMFunctionCompiler::buildReturn):
733         (JSC::WASMFunctionCompiler::callAndUnboxResult):
734         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):
735
736 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
737
738         JavaScriptCore should discard baseline code after some time
739         https://bugs.webkit.org/show_bug.cgi?id=149220
740
741         Reviewed by Saam Barati.
742
743         This is a bit more complicated than discarding optimized code because
744         the engine previously assumed that we would never discard baseline code.
745
746         * bytecode/CodeBlock.cpp:
747         (JSC::CodeBlock::CodeBlock): Record creation time (and compute time since
748         creation) instead of install time because CodeBlocks can be installed
749         more than once, and we don't want to have to worry about edge cases
750         created by CodeBlocks seeming to get younger.
751
752         (JSC::CodeBlock::visitAggregate): Be explicit about only doing the 
753         weak reference fixpoint for optimized CodeBlocks. We used to avoid the
754         fixpoint for baseline CodeBlocks implicitly, since they would always
755         visit themselves strongly right away. But now baseline CodeBlocks might
756         not visit themselves strongly, since they might choose to jettison due
757         to old age.
758
759         (JSC::CodeBlock::shouldVisitStrongly): Add old age as a reason not to
760         visit ourselves strongly, so that baseline CodeBlocks can jettison due
761         to old age.
762
763         (JSC::CodeBlock::shouldJettisonDueToWeakReference): Be explicit about
764         only jettisoning optimized CodeBlocks due to weak references so that we
765         don't confuse ourselves into thinking that we will jettison a baseline
766         CodeBlock due to weak references.
767
768         (JSC::CodeBlock::shouldJettisonDueToOldAge): Updated to use creation time.
769
770         (JSC::CodeBlock::visitOSRExitTargets): Clarify a comment and add an
771         ASSERT to help record some things I discovered while debugging.
772
773         (JSC::CodeBlock::jettison): Allow a baseline CodeBlock to jettison. Don't
774         assume that we have an alternative or a profiler.
775
776         (JSC::CodeBlock::install): Deleted.
777         * bytecode/CodeBlock.h:
778         (JSC::CodeBlock::releaseAlternative): Deleted.
779         (JSC::CodeBlock::setInstallTime): Deleted.
780         (JSC::CodeBlock::timeSinceInstall): Deleted.
781
782         * dfg/DFGOSRExitPreparation.cpp:
783         (JSC::DFG::prepareCodeOriginForOSRExit): Simplified the computation of
784         baseline CodeBlock.
785
786         * dfg/DFGPlan.cpp:
787         (JSC::DFG::Plan::checkLivenessAndVisitChildren): Be sure to strongly
788         visit our inline callframes because we assume that an optimized CodeBlock
789         will keep its OSR exit targets alive, but the CodeBlock object won't be
790         able to mark them for itself until compilation has completed (since it
791         won't have a JITCode object yet).
792
793         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
794         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
795         Updated for interface change.
796
797         * jit/JITCode.h:
798         (JSC::JITCode::timeToLive): Provide a time to live for interpreter and
799         baseline code, so they will jettison when old. Use seconds in our
800         code so that we don't need comments. Make DFG 2X interpreter+baseline,
801         and FTL 2X DFG+interpreter+baseline, also matching the time we allot
802         before throwing away all code.
803
804         * jit/JITToDFGDeferredCompilationCallback.cpp:
805         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
806         * llint/LLIntSlowPaths.cpp:
807         (JSC::LLInt::jitCompileAndSetHeuristics): Updated for interface change.
808
809         * runtime/Executable.cpp:
810         (JSC::ScriptExecutable::installCode): Allow our caller to install nullptr,
811         since we need to do this when jettisoning a baseline CodeBlock. Require
812         our caller to specify the details of the installation because we can't
813         rely on a non-null CodeBlock in order to compute them.
814
815         (JSC::ScriptExecutable::newCodeBlockFor):
816         (JSC::ScriptExecutable::prepareForExecutionImpl):
817         * runtime/Executable.h:
818         (JSC::ScriptExecutable::recordParse): Updated for interface change.
819
820         * runtime/Options.h: Renamed the CodeBlock liveness option since it now
821         controls baseline and optimized code.
822
823 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
824
825         Remove obsolete code for deleting CodeBlocks
826         https://bugs.webkit.org/show_bug.cgi?id=149231
827
828         Reviewed by Mark Lam.
829
830         * heap/Heap.cpp:
831         (JSC::Heap::deleteAllCodeBlocks): ASSERT that we're called in a valid
832         state, and do the compiler waiting ourselves instead of having our
833         caller do it. This is more appropriate to our new limited use.
834
835         (JSC::Heap::collectImpl):
836         (JSC::Heap::deleteOldCode): Deleted. Don't call deleteAllCodeBlocks
837         periodically because it's not such a good idea to delete everything
838         at once, and CodeBlocks now have a more precise individual policy for
839         when to delete. Also, this function used to fail all or nearly all of
840         the time because its invariants that we were not executing or compiling
841         could not be met.
842
843         * heap/Heap.h:
844
845         * jsc.cpp:
846         (GlobalObject::finishCreation):
847         (functionDeleteAllCompiledCode): Deleted.
848         * tests/stress/deleteAllCompiledCode.js: Removed. Removed this testing
849         code because it did not do what it thought it did. All of this code
850         was guaranteed to no-op since it would run JavaScript to call a function
851         that would return early because JavaScript was running.
852
853         * runtime/VM.cpp:
854         (JSC::VM::deleteAllCode): This code is simpler now becaue 
855         heap.deleteAllCodeBlocks does some work for us.
856
857         * runtime/VMEntryScope.cpp:
858         (JSC::VMEntryScope::VMEntryScope): Don't delete code on VM entry. This
859         policy was old, and it dated back to a time when we 
860
861             (a) couldn't run in the interpreter if compilation failed;
862
863             (b) didn't reduce the rate of compilation in response to executable
864             memory pressure;
865
866             (c) didn't throw away individual CodeBlocks automatically.
867
868 2015-09-16  Michael Saboff  <msaboff@apple.com>
869
870         [ES6] Implement tail calls in the LLInt and Baseline JIT
871         https://bugs.webkit.org/show_bug.cgi?id=148661
872
873         Fix for the breakage of Speedometer/Full.html (https://bugs.webkit.org/show_bug.cgi?id=149162).
874
875         Reviewed by Filip Pizlo.
876         Changed SetupVarargsFrame.cpp::emitSetVarargsFrame to align the callframe size to be a
877         multiple of stackAlignmentRegisters() in addition to the location of the new frame.
878
879         Fixed Reviewed by Filip Pizlo.
880
881         * CMakeLists.txt:
882         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
883         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
884         * JavaScriptCore.xcodeproj/project.pbxproj:
885         * assembler/AbortReason.h:
886         * assembler/AbstractMacroAssembler.h:
887         (JSC::AbstractMacroAssembler::Call::Call):
888         (JSC::AbstractMacroAssembler::repatchNearCall):
889         (JSC::AbstractMacroAssembler::repatchCompact):
890         * assembler/CodeLocation.h:
891         (JSC::CodeLocationNearCall::CodeLocationNearCall):
892         (JSC::CodeLocationNearCall::callMode):
893         (JSC::CodeLocationCommon::callAtOffset):
894         (JSC::CodeLocationCommon::nearCallAtOffset):
895         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
896         * assembler/LinkBuffer.h:
897         (JSC::LinkBuffer::locationOfNearCall):
898         (JSC::LinkBuffer::locationOf):
899         * assembler/MacroAssemblerARM.h:
900         (JSC::MacroAssemblerARM::nearCall):
901         (JSC::MacroAssemblerARM::nearTailCall):
902         (JSC::MacroAssemblerARM::call):
903         (JSC::MacroAssemblerARM::linkCall):
904         * assembler/MacroAssemblerARM64.h:
905         (JSC::MacroAssemblerARM64::nearCall):
906         (JSC::MacroAssemblerARM64::nearTailCall):
907         (JSC::MacroAssemblerARM64::ret):
908         (JSC::MacroAssemblerARM64::linkCall):
909         * assembler/MacroAssemblerARMv7.h:
910         (JSC::MacroAssemblerARMv7::nearCall):
911         (JSC::MacroAssemblerARMv7::nearTailCall):
912         (JSC::MacroAssemblerARMv7::call):
913         (JSC::MacroAssemblerARMv7::linkCall):
914         * assembler/MacroAssemblerMIPS.h:
915         (JSC::MacroAssemblerMIPS::nearCall):
916         (JSC::MacroAssemblerMIPS::nearTailCall):
917         (JSC::MacroAssemblerMIPS::call):
918         (JSC::MacroAssemblerMIPS::linkCall):
919         (JSC::MacroAssemblerMIPS::repatchCall):
920         * assembler/MacroAssemblerSH4.h:
921         (JSC::MacroAssemblerSH4::call):
922         (JSC::MacroAssemblerSH4::nearTailCall):
923         (JSC::MacroAssemblerSH4::nearCall):
924         (JSC::MacroAssemblerSH4::linkCall):
925         (JSC::MacroAssemblerSH4::repatchCall):
926         * assembler/MacroAssemblerX86.h:
927         (JSC::MacroAssemblerX86::linkCall):
928         * assembler/MacroAssemblerX86Common.h:
929         (JSC::MacroAssemblerX86Common::breakpoint):
930         (JSC::MacroAssemblerX86Common::nearTailCall):
931         (JSC::MacroAssemblerX86Common::nearCall):
932         * assembler/MacroAssemblerX86_64.h:
933         (JSC::MacroAssemblerX86_64::linkCall):
934         * bytecode/BytecodeList.json:
935         * bytecode/BytecodeUseDef.h:
936         (JSC::computeUsesForBytecodeOffset):
937         (JSC::computeDefsForBytecodeOffset):
938         * bytecode/CallLinkInfo.h:
939         (JSC::CallLinkInfo::callTypeFor):
940         (JSC::CallLinkInfo::isVarargsCallType):
941         (JSC::CallLinkInfo::CallLinkInfo):
942         (JSC::CallLinkInfo::specializationKind):
943         (JSC::CallLinkInfo::callModeFor):
944         (JSC::CallLinkInfo::callMode):
945         (JSC::CallLinkInfo::isTailCall):
946         (JSC::CallLinkInfo::isVarargs):
947         (JSC::CallLinkInfo::registerPreservationMode):
948         * bytecode/CallLinkStatus.cpp:
949         (JSC::CallLinkStatus::computeFromLLInt):
950         * bytecode/CodeBlock.cpp:
951         (JSC::CodeBlock::dumpBytecode):
952         (JSC::CodeBlock::CodeBlock):
953         * bytecompiler/BytecodeGenerator.cpp:
954         (JSC::BytecodeGenerator::BytecodeGenerator):
955         (JSC::BytecodeGenerator::emitCallInTailPosition):
956         (JSC::BytecodeGenerator::emitCallEval):
957         (JSC::BytecodeGenerator::emitCall):
958         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
959         (JSC::BytecodeGenerator::emitConstructVarargs):
960         * bytecompiler/NodesCodegen.cpp:
961         (JSC::CallArguments::CallArguments):
962         (JSC::LabelNode::emitBytecode):
963         * dfg/DFGByteCodeParser.cpp:
964         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
965         * ftl/FTLLowerDFGToLLVM.cpp:
966         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
967         * interpreter/Interpreter.h:
968         (JSC::Interpreter::isCallBytecode):
969         (JSC::calleeFrameForVarargs):
970         * jit/CCallHelpers.h:
971         (JSC::CCallHelpers::jumpToExceptionHandler):
972         (JSC::CCallHelpers::prepareForTailCallSlow):
973         * jit/JIT.cpp:
974         (JSC::JIT::privateCompileMainPass):
975         (JSC::JIT::privateCompileSlowCases):
976         * jit/JIT.h:
977         * jit/JITCall.cpp:
978         (JSC::JIT::compileOpCall):
979         (JSC::JIT::compileOpCallSlowCase):
980         (JSC::JIT::emit_op_call):
981         (JSC::JIT::emit_op_tail_call):
982         (JSC::JIT::emit_op_call_eval):
983         (JSC::JIT::emit_op_call_varargs):
984         (JSC::JIT::emit_op_tail_call_varargs):
985         (JSC::JIT::emit_op_construct_varargs):
986         (JSC::JIT::emitSlow_op_call):
987         (JSC::JIT::emitSlow_op_tail_call):
988         (JSC::JIT::emitSlow_op_call_eval):
989         (JSC::JIT::emitSlow_op_call_varargs):
990         (JSC::JIT::emitSlow_op_tail_call_varargs):
991         (JSC::JIT::emitSlow_op_construct_varargs):
992         * jit/JITCall32_64.cpp:
993         (JSC::JIT::emitSlow_op_call):
994         (JSC::JIT::emitSlow_op_tail_call):
995         (JSC::JIT::emitSlow_op_call_eval):
996         (JSC::JIT::emitSlow_op_call_varargs):
997         (JSC::JIT::emitSlow_op_tail_call_varargs):
998         (JSC::JIT::emitSlow_op_construct_varargs):
999         (JSC::JIT::emit_op_call):
1000         (JSC::JIT::emit_op_tail_call):
1001         (JSC::JIT::emit_op_call_eval):
1002         (JSC::JIT::emit_op_call_varargs):
1003         (JSC::JIT::emit_op_tail_call_varargs):
1004         (JSC::JIT::emit_op_construct_varargs):
1005         (JSC::JIT::compileOpCall):
1006         (JSC::JIT::compileOpCallSlowCase):
1007         * jit/JITInlines.h:
1008         (JSC::JIT::emitNakedCall):
1009         (JSC::JIT::emitNakedTailCall):
1010         (JSC::JIT::updateTopCallFrame):
1011         * jit/JITOperations.cpp:
1012         * jit/JITOperations.h:
1013         * jit/Repatch.cpp:
1014         (JSC::linkVirtualFor):
1015         (JSC::linkPolymorphicCall):
1016         * jit/SetupVarargsFrame.cpp:
1017         (JSC::emitSetVarargsFrame):
1018         * jit/ThunkGenerators.cpp:
1019         (JSC::throwExceptionFromCallSlowPathGenerator):
1020         (JSC::slowPathFor):
1021         (JSC::linkCallThunkGenerator):
1022         (JSC::virtualThunkFor):
1023         (JSC::arityFixupGenerator):
1024         (JSC::unreachableGenerator):
1025         (JSC::baselineGetterReturnThunkGenerator):
1026         * jit/ThunkGenerators.h:
1027         * llint/LowLevelInterpreter.asm:
1028         * llint/LowLevelInterpreter32_64.asm:
1029         * llint/LowLevelInterpreter64.asm:
1030         * runtime/CommonSlowPaths.h:
1031         (JSC::CommonSlowPaths::arityCheckFor):
1032         (JSC::CommonSlowPaths::opIn):
1033
1034 2015-09-15  Michael Saboff  <msaboff@apple.com>
1035
1036         Rollout r189774 and 189818.
1037
1038         Broke Speedometer/Full.html
1039
1040         Not reviewed.
1041
1042         * CMakeLists.txt:
1043         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1044         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1045         * JavaScriptCore.xcodeproj/project.pbxproj:
1046         * assembler/AbortReason.h:
1047         * assembler/AbstractMacroAssembler.h:
1048         (JSC::AbstractMacroAssembler::Call::Call):
1049         (JSC::AbstractMacroAssembler::repatchNearCall):
1050         (JSC::AbstractMacroAssembler::repatchCompact):
1051         * assembler/CodeLocation.h:
1052         (JSC::CodeLocationNearCall::CodeLocationNearCall):
1053         (JSC::CodeLocationCommon::callAtOffset):
1054         (JSC::CodeLocationCommon::nearCallAtOffset):
1055         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
1056         (JSC::CodeLocationNearCall::callMode): Deleted.
1057         * assembler/LinkBuffer.h:
1058         (JSC::LinkBuffer::locationOfNearCall):
1059         (JSC::LinkBuffer::locationOf):
1060         * assembler/MacroAssemblerARM.h:
1061         (JSC::MacroAssemblerARM::nearCall):
1062         (JSC::MacroAssemblerARM::call):
1063         (JSC::MacroAssemblerARM::linkCall):
1064         (JSC::MacroAssemblerARM::nearTailCall): Deleted.
1065         * assembler/MacroAssemblerARM64.h:
1066         (JSC::MacroAssemblerARM64::nearCall):
1067         (JSC::MacroAssemblerARM64::ret):
1068         (JSC::MacroAssemblerARM64::linkCall):
1069         (JSC::MacroAssemblerARM64::nearTailCall): Deleted.
1070         * assembler/MacroAssemblerARMv7.h:
1071         (JSC::MacroAssemblerARMv7::nearCall):
1072         (JSC::MacroAssemblerARMv7::call):
1073         (JSC::MacroAssemblerARMv7::linkCall):
1074         (JSC::MacroAssemblerARMv7::nearTailCall): Deleted.
1075         * assembler/MacroAssemblerMIPS.h:
1076         (JSC::MacroAssemblerMIPS::nearCall):
1077         (JSC::MacroAssemblerMIPS::call):
1078         (JSC::MacroAssemblerMIPS::linkCall):
1079         (JSC::MacroAssemblerMIPS::repatchCall):
1080         (JSC::MacroAssemblerMIPS::nearTailCall): Deleted.
1081         * assembler/MacroAssemblerSH4.h:
1082         (JSC::MacroAssemblerSH4::call):
1083         (JSC::MacroAssemblerSH4::nearCall):
1084         (JSC::MacroAssemblerSH4::linkCall):
1085         (JSC::MacroAssemblerSH4::repatchCall):
1086         (JSC::MacroAssemblerSH4::nearTailCall): Deleted.
1087         * assembler/MacroAssemblerX86.h:
1088         (JSC::MacroAssemblerX86::linkCall):
1089         * assembler/MacroAssemblerX86Common.h:
1090         (JSC::MacroAssemblerX86Common::breakpoint):
1091         (JSC::MacroAssemblerX86Common::nearCall):
1092         (JSC::MacroAssemblerX86Common::nearTailCall): Deleted.
1093         * assembler/MacroAssemblerX86_64.h:
1094         (JSC::MacroAssemblerX86_64::linkCall):
1095         * bytecode/BytecodeList.json:
1096         * bytecode/BytecodeUseDef.h:
1097         (JSC::computeUsesForBytecodeOffset):
1098         (JSC::computeDefsForBytecodeOffset):
1099         * bytecode/CallLinkInfo.h:
1100         (JSC::CallLinkInfo::callTypeFor):
1101         (JSC::CallLinkInfo::CallLinkInfo):
1102         (JSC::CallLinkInfo::specializationKind):
1103         (JSC::CallLinkInfo::registerPreservationMode):
1104         (JSC::CallLinkInfo::isVarargsCallType): Deleted.
1105         (JSC::CallLinkInfo::callModeFor): Deleted.
1106         (JSC::CallLinkInfo::callMode): Deleted.
1107         (JSC::CallLinkInfo::isTailCall): Deleted.
1108         (JSC::CallLinkInfo::isVarargs): Deleted.
1109         * bytecode/CallLinkStatus.cpp:
1110         (JSC::CallLinkStatus::computeFromLLInt):
1111         * bytecode/CodeBlock.cpp:
1112         (JSC::CodeBlock::dumpBytecode):
1113         (JSC::CodeBlock::CodeBlock):
1114         * bytecompiler/BytecodeGenerator.cpp:
1115         (JSC::BytecodeGenerator::BytecodeGenerator):
1116         (JSC::BytecodeGenerator::emitCallInTailPosition):
1117         (JSC::BytecodeGenerator::emitCallEval):
1118         (JSC::BytecodeGenerator::emitCall):
1119         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
1120         (JSC::BytecodeGenerator::emitConstructVarargs):
1121         * bytecompiler/NodesCodegen.cpp:
1122         (JSC::CallArguments::CallArguments):
1123         (JSC::LabelNode::emitBytecode):
1124         * dfg/DFGByteCodeParser.cpp:
1125         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
1126         * ftl/FTLLowerDFGToLLVM.cpp:
1127         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
1128         * interpreter/Interpreter.h:
1129         (JSC::Interpreter::isCallBytecode):
1130         * jit/CCallHelpers.h:
1131         (JSC::CCallHelpers::jumpToExceptionHandler):
1132         (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
1133         * jit/JIT.cpp:
1134         (JSC::JIT::privateCompileMainPass):
1135         (JSC::JIT::privateCompileSlowCases):
1136         * jit/JIT.h:
1137         * jit/JITCall.cpp:
1138         (JSC::JIT::compileOpCall):
1139         (JSC::JIT::compileOpCallSlowCase):
1140         (JSC::JIT::emit_op_call):
1141         (JSC::JIT::emit_op_call_eval):
1142         (JSC::JIT::emit_op_call_varargs):
1143         (JSC::JIT::emit_op_construct_varargs):
1144         (JSC::JIT::emitSlow_op_call):
1145         (JSC::JIT::emitSlow_op_call_eval):
1146         (JSC::JIT::emitSlow_op_call_varargs):
1147         (JSC::JIT::emitSlow_op_construct_varargs):
1148         (JSC::JIT::emit_op_tail_call): Deleted.
1149         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
1150         (JSC::JIT::emitSlow_op_tail_call): Deleted.
1151         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
1152         * jit/JITCall32_64.cpp:
1153         (JSC::JIT::emitSlow_op_call):
1154         (JSC::JIT::emitSlow_op_call_eval):
1155         (JSC::JIT::emitSlow_op_call_varargs):
1156         (JSC::JIT::emitSlow_op_construct_varargs):
1157         (JSC::JIT::emit_op_call):
1158         (JSC::JIT::emit_op_call_eval):
1159         (JSC::JIT::emit_op_call_varargs):
1160         (JSC::JIT::emit_op_construct_varargs):
1161         (JSC::JIT::compileOpCall):
1162         (JSC::JIT::compileOpCallSlowCase):
1163         (JSC::JIT::emitSlow_op_tail_call): Deleted.
1164         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
1165         (JSC::JIT::emit_op_tail_call): Deleted.
1166         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
1167         * jit/JITInlines.h:
1168         (JSC::JIT::emitNakedCall):
1169         (JSC::JIT::updateTopCallFrame):
1170         (JSC::JIT::emitNakedTailCall): Deleted.
1171         * jit/JITOperations.cpp:
1172         * jit/JITOperations.h:
1173         * jit/Repatch.cpp:
1174         (JSC::linkVirtualFor):
1175         (JSC::linkPolymorphicCall):
1176         * jit/ThunkGenerators.cpp:
1177         (JSC::throwExceptionFromCallSlowPathGenerator):
1178         (JSC::slowPathFor):
1179         (JSC::linkCallThunkGenerator):
1180         (JSC::virtualThunkFor):
1181         (JSC::arityFixupGenerator):
1182         (JSC::baselineGetterReturnThunkGenerator):
1183         (JSC::unreachableGenerator): Deleted.
1184         * jit/ThunkGenerators.h:
1185         * llint/LowLevelInterpreter.asm:
1186         * llint/LowLevelInterpreter32_64.asm:
1187         * llint/LowLevelInterpreter64.asm:
1188         * runtime/CommonSlowPaths.h:
1189         (JSC::CommonSlowPaths::arityCheckFor):
1190         (JSC::CommonSlowPaths::opIn):
1191         * tests/stress/mutual-tail-call-no-stack-overflow.js: Removed.
1192         * tests/stress/tail-call-no-stack-overflow.js: Removed.
1193         * tests/stress/tail-call-recognize.js: Removed.
1194         * tests/stress/tail-call-varargs-no-stack-overflow.js: Removed.
1195         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Removed.
1196
1197 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1198
1199         Implement imported global variables in WebAssembly
1200         https://bugs.webkit.org/show_bug.cgi?id=149206
1201
1202         Reviewed by Filip Pizlo.
1203
1204         Values can now be imported to a WebAssembly module through properties of
1205         the imports object that is passed to loadWebAssembly(). In order to
1206         avoid any side effect when accessing the imports object, we check that
1207         the properties are data properties. We also check that each value is a
1208         primitive and is not a Symbol. According to the ECMA262 6.0 spec,
1209         calling ToNumber() on a primitive that is not a Symbol should not cause
1210         any side effect.[1]
1211
1212         [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-tonumber
1213
1214         * tests/stress/wasm-globals.js:
1215         * tests/stress/wasm/globals.wasm:
1216         * wasm/WASMModuleParser.cpp:
1217         (JSC::WASMModuleParser::parseModule):
1218         (JSC::WASMModuleParser::parseGlobalSection):
1219         * wasm/WASMModuleParser.h:
1220
1221 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1222
1223         Fix asm.js errors in WebAssembly tests
1224         https://bugs.webkit.org/show_bug.cgi?id=149203
1225
1226         Reviewed by Geoffrey Garen.
1227
1228         Our WebAssembly implementation uses asm.js for testing. Using Firefox to
1229         parse asm.js reveals many errors that are not caught by pack-asmjs. For
1230         example,
1231         - asm.js does not allow the use of the multiplication operator (*) to
1232           multiply two integers, because the result can be so large that some
1233           lower bits of precision are lost. Math.imul is used instead.
1234         - an int variable must be coerced to either signed (via x|0) or unsigned
1235           (via x>>>0) before it's returned.
1236
1237         * tests/stress/wasm-arithmetic-int32.js:
1238         * tests/stress/wasm-calls.js:
1239         * tests/stress/wasm-control-flow.js:
1240         * tests/stress/wasm-globals.js:
1241         * tests/stress/wasm-locals.js:
1242         * tests/stress/wasm-relational.js:
1243         * tests/stress/wasm/control-flow.wasm:
1244
1245 2015-09-15  Ryosuke Niwa  <rniwa@webkit.org>
1246
1247         Add ShadowRoot interface and Element.prototype.attachShadow
1248         https://bugs.webkit.org/show_bug.cgi?id=149187
1249
1250         Reviewed by Antti Koivisto.
1251
1252         * Configurations/FeatureDefines.xcconfig:
1253
1254 2015-09-15  Joseph Pecoraro  <pecoraro@apple.com>
1255
1256         Web Inspector: Paused Debugger prevents page reload
1257         https://bugs.webkit.org/show_bug.cgi?id=148174
1258
1259         Reviewed by Brian Burg.
1260
1261         * debugger/Debugger.h:
1262         (JSC::Debugger::suppressAllPauses):
1263         (JSC::Debugger::setSuppressAllPauses):
1264         * debugger/Debugger.cpp:
1265         (JSC::Debugger::Debugger):
1266         (JSC::Debugger::pauseIfNeeded):
1267         * inspector/agents/InspectorDebuggerAgent.h:
1268         * inspector/agents/InspectorDebuggerAgent.cpp:
1269         (Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
1270         Provide a way to suppress pauses.
1271
1272 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1273
1274         Implement calls to JavaScript functions in WebAssembly
1275         https://bugs.webkit.org/show_bug.cgi?id=149093
1276
1277         Reviewed by Filip Pizlo.
1278
1279         This patch implements calls to JavaScript functions in WebAssembly.
1280         WebAssembly functions can only call JavaScript functions that are
1281         imported to their module via an object that is passed into
1282         loadWebAssembly(). References to JavaScript functions are resolved at
1283         the module's load time, just like asm.js.
1284
1285         * jsc.cpp:
1286         (GlobalObject::finishCreation):
1287         (functionLoadWebAssembly):
1288         * tests/stress/wasm-calls.js:
1289         * tests/stress/wasm/calls.wasm:
1290         * wasm/JSWASMModule.cpp:
1291         (JSC::JSWASMModule::visitChildren):
1292         * wasm/JSWASMModule.h:
1293         (JSC::JSWASMModule::importedFunctions):
1294         * wasm/WASMFunctionCompiler.h:
1295         (JSC::WASMFunctionCompiler::buildCallImport):
1296         * wasm/WASMFunctionParser.cpp:
1297         (JSC::WASMFunctionParser::parseExpressionI32):
1298         (JSC::WASMFunctionParser::parseExpressionF64):
1299         (JSC::WASMFunctionParser::parseCallImport):
1300         * wasm/WASMFunctionParser.h:
1301         * wasm/WASMFunctionSyntaxChecker.h:
1302         (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
1303         (JSC::WASMFunctionSyntaxChecker::buildCallImport):
1304         (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):
1305         * wasm/WASMModuleParser.cpp:
1306         (JSC::WASMModuleParser::WASMModuleParser):
1307         (JSC::WASMModuleParser::parse):
1308         (JSC::WASMModuleParser::parseModule):
1309         (JSC::WASMModuleParser::parseFunctionImportSection):
1310         (JSC::WASMModuleParser::getImportedValue):
1311         (JSC::parseWebAssembly):
1312         * wasm/WASMModuleParser.h:
1313
1314 2015-09-15  Csaba Osztrogon√°c  <ossy@webkit.org>
1315
1316         Fix the !ENABLE(DFG_JIT) build after r188696
1317         https://bugs.webkit.org/show_bug.cgi?id=149158
1318
1319         Reviewed by Yusuke Suzuki.
1320
1321         * bytecode/GetByIdStatus.cpp:
1322         * bytecode/GetByIdStatus.h:
1323
1324 2015-09-15  Saam barati  <sbarati@apple.com>
1325
1326         functions that use try/catch will allocate a top level JSLexicalEnvironment even when it is not necessary
1327         https://bugs.webkit.org/show_bug.cgi?id=148169
1328
1329         Reviewed by Geoffrey Garen.
1330
1331         We used to do this before we had proper lexical scoping
1332         in the bytecode generator. There is absolutely no reason
1333         why need to allocate a top-level "var" activation when a
1334         function/program uses a "catch" block.
1335
1336         * parser/ASTBuilder.h:
1337         (JSC::ASTBuilder::createTryStatement):
1338         (JSC::ASTBuilder::incConstants):
1339         (JSC::ASTBuilder::usesThis):
1340         (JSC::ASTBuilder::usesArguments):
1341         (JSC::ASTBuilder::usesWith):
1342         (JSC::ASTBuilder::usesEval):
1343         (JSC::ASTBuilder::usesCatch): Deleted.
1344         * parser/Nodes.h:
1345         (JSC::ScopeNode::isStrictMode):
1346         (JSC::ScopeNode::setUsesArguments):
1347         (JSC::ScopeNode::usesThis):
1348         (JSC::ScopeNode::needsActivation):
1349         (JSC::ScopeNode::hasCapturedVariables):
1350         (JSC::ScopeNode::captures):
1351         (JSC::ScopeNode::needsActivationForMoreThanVariables): Deleted.
1352         * parser/ParserModes.h:
1353         * runtime/Executable.h:
1354         (JSC::ScriptExecutable::usesEval):
1355         (JSC::ScriptExecutable::usesArguments):
1356         (JSC::ScriptExecutable::needsActivation):
1357         (JSC::ScriptExecutable::isStrictMode):
1358         (JSC::ScriptExecutable::ecmaMode):
1359
1360 2015-09-15  Michael Saboff  <msaboff@apple.com>
1361
1362         REGRESSION(r189774): CLoop doesn't build after r189774
1363         https://bugs.webkit.org/show_bug.cgi?id=149171
1364
1365         Unreviewed build fix for the C Loop.
1366
1367         Added needed C Loop label opcodes.
1368
1369         * bytecode/BytecodeList.json:
1370
1371 2015-09-15  Andy VanWagoner  <thetalecrafter@gmail.com>
1372
1373         [INTL] Implement supportedLocalesOf on Intl Constructors
1374         https://bugs.webkit.org/show_bug.cgi?id=147599
1375
1376         Reviewed by Benjamin Poulain.
1377
1378         Implements all of the abstract operations used by supportedLocalesOf,
1379         except during canonicalization it does not replace redundant tags,
1380         or subtags with their preferred values.
1381
1382         * icu/unicode/ucal.h: Added.
1383         * icu/unicode/udat.h: Added.
1384         * icu/unicode/umisc.h: Added.
1385         * icu/unicode/unum.h: Added.
1386         * icu/unicode/utypes.h: Clear the U_SHOW_CPLUSPLUS_API flag to prevent C++ headers from being included.
1387         * runtime/CommonIdentifiers.h: Adde localeMatcher.
1388         * runtime/IntlCollatorConstructor.cpp:
1389         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Implemented.
1390         * runtime/IntlDateTimeFormatConstructor.cpp:
1391         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Implemented.
1392         * runtime/IntlNumberFormatConstructor.cpp:
1393         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Implemented.
1394         * runtime/IntlObject.cpp:
1395         (JSC::canonicalizeLanguageTag):
1396         (JSC::getCanonicalLangTag):
1397         (JSC::getPrivateUseLangTag):
1398         (JSC::getGrandfatheredLangTag):
1399         (JSC::canonicalizeLocaleList):
1400         (JSC::bestAvailableLocale):
1401         (JSC::lookupSupportedLocales):
1402         (JSC::bestFitSupportedLocales):
1403         (JSC::supportedLocales):
1404         (JSC::getIntlStringOption):
1405         (JSC::getIntlBooleanOption):
1406         * runtime/IntlObject.h:
1407         * runtime/JSCJSValue.h: Added toLength.
1408         * runtime/JSCJSValue.cpp: Added toLength.
1409         (JSC::JSValue::toLength): Implement ToLength from ECMA 262 6.0 7.1.15
1410         * runtime/JSGlobalObject.cpp:
1411         (JSC::JSGlobalObject::intlCollatorAvailableLocales): Added lazy locale list.
1412         (JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales): Added lazy locale list.
1413         (JSC::JSGlobalObject::intlNumberFormatAvailableLocales): Added lazy locale list.
1414         * runtime/JSGlobalObject.h:
1415
1416 2015-09-14  Saam barati  <sbarati@apple.com>
1417
1418         rename callFrameForThrow to callFrameForCatch
1419         https://bugs.webkit.org/show_bug.cgi?id=149136
1420
1421         Reviewed by Michael Saboff.
1422
1423         We use "callFrameForThrow" to mean the call frame in
1424         which we're catching the exception. The field name
1425         should accurately represent its purpose by being
1426         named "callFrameForCatch".
1427
1428         * jit/CCallHelpers.h:
1429         (JSC::CCallHelpers::jumpToExceptionHandler):
1430         * jit/JITExceptions.cpp:
1431         (JSC::genericUnwind):
1432         * jit/JITOpcodes.cpp:
1433         (JSC::JIT::emit_op_catch):
1434         * jit/JITOpcodes32_64.cpp:
1435         (JSC::JIT::emit_op_catch):
1436         * jit/JITOperations.cpp:
1437         * llint/LowLevelInterpreter32_64.asm:
1438         * llint/LowLevelInterpreter64.asm:
1439         * runtime/VM.h:
1440         (JSC::VM::exceptionOffset):
1441         (JSC::VM::callFrameForCatchOffset):
1442         (JSC::VM::targetMachinePCForThrowOffset):
1443         (JSC::VM::callFrameForThrowOffset): Deleted.
1444
1445 2015-09-14  Basile Clement  <basile_clement@apple.com>
1446
1447         [ES6] Implement tail calls in the LLInt and Baseline JIT
1448         https://bugs.webkit.org/show_bug.cgi?id=148661
1449
1450         Reviewed by Filip Pizlo.
1451
1452         This patch introduces two new opcodes, op_tail_call and
1453         op_tail_call_varargs, to perform tail calls, and implements them in the
1454         LLInt and baseline JIT. Their use prevents DFG and FTL compilation for
1455         now. They are currently implemented by sliding the call frame and
1456         masquerading as our own caller right before performing an actual call.
1457
1458         This required to change the operationLink family of operation to return
1459         a SlowPathReturnType instead of a char* in order to distinguish between
1460         exception cases and actual call cases. We introduce a new FrameAction
1461         enum that indicates whether to reuse (non-exceptional tail call) or
1462         keep the current call frame (non-tail call, and exceptional cases).
1463
1464         This is also a semantics change, since the Function.caller property is
1465         now leaking tail calls. Since tail calls are only used in strict mode,
1466         which poisons this property, the only way of seeing this semantics
1467         change is when a sloppy function calls a strict function that then
1468         tail-calls a sloppy function. Previously, the second sloppy function's
1469         caller would have been the strict function (i.e. raises a TypeError
1470         when the .caller attribute is accessed), while it is now the first
1471         sloppy function. Tests have been updated to reflect that.
1472
1473         This also changes the assumptions we make about call frames. In order
1474         to be relatively efficient, we want to be able to compute the frame
1475         size based only on the argument count, which was not possible
1476         previously. To enable this, we now enforce at the bytecode generator,
1477         DFG and FTL level that any space reserved for a call frame is
1478         stack-aligned, which allows to easily compute its size when performing
1479         a tail call. In all the "special call cases" (calls from native code,
1480         inlined cache calls, etc.), we are starting the frame at the current
1481         stack pointer and thus will always have a stack-aligned frame size.
1482
1483         Finally, this patch adds a couple of tests to check that tail calls run
1484         in constant stack space, as well as tests checking that tail calls are
1485         recognized correctly. Those tests use the handy aforementioned leaking
1486         of tail calls through Function.caller to detect tail calls. 
1487
1488         Given that this patch only implements tail calls for the LLInt and
1489         Baseline JIT, tail calls are disabled by default.  Until changes are
1490         landed for all tiers, tail call testing and use requires the
1491         --enableTailCalls=true or equivalent.
1492
1493         * CMakeLists.txt:
1494         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1495         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1496         * JavaScriptCore.xcodeproj/project.pbxproj:
1497         * assembler/AbortReason.h:
1498         * assembler/AbstractMacroAssembler.h:
1499         (JSC::AbstractMacroAssembler::Call::Call):
1500         (JSC::AbstractMacroAssembler::repatchNearCall):
1501         (JSC::AbstractMacroAssembler::repatchCompact):
1502         * assembler/CodeLocation.h:
1503         (JSC::CodeLocationNearCall::CodeLocationNearCall):
1504         (JSC::CodeLocationNearCall::callMode):
1505         (JSC::CodeLocationCommon::callAtOffset):
1506         (JSC::CodeLocationCommon::nearCallAtOffset):
1507         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
1508         * assembler/LinkBuffer.h:
1509         (JSC::LinkBuffer::locationOfNearCall):
1510         (JSC::LinkBuffer::locationOf):
1511         * assembler/MacroAssemblerARM.h:
1512         (JSC::MacroAssemblerARM::nearCall):
1513         (JSC::MacroAssemblerARM::nearTailCall):
1514         (JSC::MacroAssemblerARM::call):
1515         (JSC::MacroAssemblerARM::linkCall):
1516         * assembler/MacroAssemblerARM64.h:
1517         (JSC::MacroAssemblerARM64::nearCall):
1518         (JSC::MacroAssemblerARM64::nearTailCall):
1519         (JSC::MacroAssemblerARM64::ret):
1520         (JSC::MacroAssemblerARM64::linkCall):
1521         * assembler/MacroAssemblerARMv7.h:
1522         (JSC::MacroAssemblerARMv7::nearCall):
1523         (JSC::MacroAssemblerARMv7::nearTailCall):
1524         (JSC::MacroAssemblerARMv7::call):
1525         (JSC::MacroAssemblerARMv7::linkCall):
1526         * assembler/MacroAssemblerMIPS.h:
1527         (JSC::MacroAssemblerMIPS::nearCall):
1528         (JSC::MacroAssemblerMIPS::nearTailCall):
1529         (JSC::MacroAssemblerMIPS::call):
1530         (JSC::MacroAssemblerMIPS::linkCall):
1531         (JSC::MacroAssemblerMIPS::repatchCall):
1532         * assembler/MacroAssemblerSH4.h:
1533         (JSC::MacroAssemblerSH4::call):
1534         (JSC::MacroAssemblerSH4::nearTailCall):
1535         (JSC::MacroAssemblerSH4::nearCall):
1536         (JSC::MacroAssemblerSH4::linkCall):
1537         (JSC::MacroAssemblerSH4::repatchCall):
1538         * assembler/MacroAssemblerX86.h:
1539         (JSC::MacroAssemblerX86::linkCall):
1540         * assembler/MacroAssemblerX86Common.h:
1541         (JSC::MacroAssemblerX86Common::breakpoint):
1542         (JSC::MacroAssemblerX86Common::nearTailCall):
1543         (JSC::MacroAssemblerX86Common::nearCall):
1544         * assembler/MacroAssemblerX86_64.h:
1545         (JSC::MacroAssemblerX86_64::linkCall):
1546         * bytecode/BytecodeList.json:
1547         * bytecode/BytecodeUseDef.h:
1548         (JSC::computeUsesForBytecodeOffset):
1549         (JSC::computeDefsForBytecodeOffset):
1550         * bytecode/CallLinkInfo.h:
1551         (JSC::CallLinkInfo::callTypeFor):
1552         (JSC::CallLinkInfo::isVarargsCallType):
1553         (JSC::CallLinkInfo::CallLinkInfo):
1554         (JSC::CallLinkInfo::specializationKind):
1555         (JSC::CallLinkInfo::callModeFor):
1556         (JSC::CallLinkInfo::callMode):
1557         (JSC::CallLinkInfo::isTailCall):
1558         (JSC::CallLinkInfo::isVarargs):
1559         (JSC::CallLinkInfo::registerPreservationMode):
1560         * bytecode/CallLinkStatus.cpp:
1561         (JSC::CallLinkStatus::computeFromLLInt):
1562         * bytecode/CallMode.cpp: Added.
1563         (WTF::printInternal):
1564         * bytecode/CallMode.h: Added.
1565         * bytecode/CodeBlock.cpp:
1566         (JSC::CodeBlock::dumpBytecode):
1567         (JSC::CodeBlock::CodeBlock):
1568         * bytecompiler/BytecodeGenerator.cpp:
1569         (JSC::BytecodeGenerator::BytecodeGenerator):
1570         (JSC::BytecodeGenerator::emitCallInTailPosition):
1571         (JSC::BytecodeGenerator::emitCallEval):
1572         (JSC::BytecodeGenerator::emitCall):
1573         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
1574         (JSC::BytecodeGenerator::emitConstructVarargs):
1575         * bytecompiler/NodesCodegen.cpp:
1576         (JSC::CallArguments::CallArguments):
1577         (JSC::LabelNode::emitBytecode):
1578         * dfg/DFGByteCodeParser.cpp:
1579         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
1580         * ftl/FTLLowerDFGToLLVM.cpp:
1581         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
1582         * interpreter/Interpreter.h:
1583         (JSC::Interpreter::isCallBytecode):
1584         * jit/CCallHelpers.h:
1585         (JSC::CCallHelpers::jumpToExceptionHandler):
1586         (JSC::CCallHelpers::prepareForTailCallSlow):
1587         * jit/JIT.cpp:
1588         (JSC::JIT::privateCompileMainPass):
1589         (JSC::JIT::privateCompileSlowCases):
1590         * jit/JIT.h:
1591         * jit/JITCall.cpp:
1592         (JSC::JIT::compileOpCall):
1593         (JSC::JIT::compileOpCallSlowCase):
1594         (JSC::JIT::emit_op_call):
1595         (JSC::JIT::emit_op_tail_call):
1596         (JSC::JIT::emit_op_call_eval):
1597         (JSC::JIT::emit_op_call_varargs):
1598         (JSC::JIT::emit_op_tail_call_varargs):
1599         (JSC::JIT::emit_op_construct_varargs):
1600         (JSC::JIT::emitSlow_op_call):
1601         (JSC::JIT::emitSlow_op_tail_call):
1602         (JSC::JIT::emitSlow_op_call_eval):
1603         (JSC::JIT::emitSlow_op_call_varargs):
1604         (JSC::JIT::emitSlow_op_tail_call_varargs):
1605         (JSC::JIT::emitSlow_op_construct_varargs):
1606         * jit/JITCall32_64.cpp:
1607         (JSC::JIT::emitSlow_op_call):
1608         (JSC::JIT::emitSlow_op_tail_call):
1609         (JSC::JIT::emitSlow_op_call_eval):
1610         (JSC::JIT::emitSlow_op_call_varargs):
1611         (JSC::JIT::emitSlow_op_tail_call_varargs):
1612         (JSC::JIT::emitSlow_op_construct_varargs):
1613         (JSC::JIT::emit_op_call):
1614         (JSC::JIT::emit_op_tail_call):
1615         (JSC::JIT::emit_op_call_eval):
1616         (JSC::JIT::emit_op_call_varargs):
1617         (JSC::JIT::emit_op_tail_call_varargs):
1618         (JSC::JIT::emit_op_construct_varargs):
1619         (JSC::JIT::compileOpCall):
1620         (JSC::JIT::compileOpCallSlowCase):
1621         * jit/JITInlines.h:
1622         (JSC::JIT::emitNakedCall):
1623         (JSC::JIT::emitNakedTailCall):
1624         (JSC::JIT::updateTopCallFrame):
1625         * jit/JITOperations.cpp:
1626         * jit/JITOperations.h:
1627         * jit/Repatch.cpp:
1628         (JSC::linkVirtualFor):
1629         (JSC::linkPolymorphicCall):
1630         * jit/ThunkGenerators.cpp:
1631         (JSC::throwExceptionFromCallSlowPathGenerator):
1632         (JSC::slowPathFor):
1633         (JSC::linkCallThunkGenerator):
1634         (JSC::virtualThunkFor):
1635         (JSC::arityFixupGenerator):
1636         (JSC::unreachableGenerator):
1637         (JSC::baselineGetterReturnThunkGenerator):
1638         * jit/ThunkGenerators.h:
1639         * llint/LowLevelInterpreter.asm:
1640         * llint/LowLevelInterpreter32_64.asm:
1641         * llint/LowLevelInterpreter64.asm:
1642         * runtime/CommonSlowPaths.h:
1643         (JSC::CommonSlowPaths::arityCheckFor):
1644         (JSC::CommonSlowPaths::opIn):
1645         * runtime/Options.h:
1646         * tests/stress/mutual-tail-call-no-stack-overflow.js: Added.
1647         (shouldThrow):
1648         (sloppyCountdown.even):
1649         (sloppyCountdown.odd):
1650         (strictCountdown.even):
1651         (strictCountdown.odd):
1652         (strictCountdown):
1653         (odd):
1654         (even):
1655         * tests/stress/tail-call-no-stack-overflow.js: Added.
1656         (shouldThrow):
1657         (strictLoop):
1658         (strictLoopArityFixup1):
1659         (strictLoopArityFixup2):
1660         * tests/stress/tail-call-recognize.js: Added.
1661         (callerMustBeRun):
1662         (callerMustBeStrict):
1663         (runTests):
1664         * tests/stress/tail-call-varargs-no-stack-overflow.js: Added.
1665         (shouldThrow):
1666         (strictLoop):
1667         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Added.
1668         (tail):
1669         (obj.method):
1670         (obj.get fromNative):
1671         (getThis):
1672
1673 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
1674
1675         LLInt get/put inline caches shouldn't use tons of opcodes
1676         https://bugs.webkit.org/show_bug.cgi?id=149106
1677
1678         Reviewed by Geoffrey Garen.
1679
1680         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
1681         example, instead of having get_by_id branch on the kind of offset (inline or
1682         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
1683         But the problem with this approach is that it doesn't scale. In the property type
1684         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
1685         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
1686         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
1687         checks, we'd have 6 * 11 = 66 variants of put_by_id).
1688
1689         So, this patch completely changes the strategy to mostly using branching inside the
1690         opcode implementation. It's unlikely to have a performance effect. For example, the long
1691         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
1692         and yet nobody noticed. The regression was because the inline cache was in terms of the
1693         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
1694         didn't notice that, then we probably won't notice a couple new branches. (Also, this
1695         patch fixes that regression - the code no longer does such lookups except in the one
1696         unavoidable case in put_by_id transition chain checking.)
1697
1698         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
1699         this flags field to encode the desired type check in bug 148610.
1700
1701         This patch has no effect on performance according to run-jsc-benchmarks.
1702
1703         Relanding this patch with LLInt fixes for non-x86. Previous attempts to fix non-x86 LLInt
1704         build also caused every 64-bit test to crash on every platform. So the patch got rolled
1705         out. This fixes the non-x86 LLInt build while also ensuring that 64-bit platforms don't
1706         crash.
1707
1708         * CMakeLists.txt:
1709         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1710         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1711         * JavaScriptCore.xcodeproj/project.pbxproj:
1712         * bytecode/BytecodeList.json:
1713         * bytecode/BytecodeUseDef.h:
1714         (JSC::computeUsesForBytecodeOffset):
1715         (JSC::computeDefsForBytecodeOffset):
1716         * bytecode/CodeBlock.cpp:
1717         (JSC::CodeBlock::printGetByIdOp):
1718         (JSC::CodeBlock::printGetByIdCacheStatus):
1719         (JSC::CodeBlock::printPutByIdCacheStatus):
1720         (JSC::CodeBlock::dumpBytecode):
1721         (JSC::CodeBlock::CodeBlock):
1722         (JSC::CodeBlock::propagateTransitions):
1723         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1724         * bytecode/CodeBlock.h:
1725         * bytecode/GetByIdStatus.cpp:
1726         (JSC::GetByIdStatus::computeFromLLInt):
1727         * bytecode/Instruction.h:
1728         (JSC::Instruction::Instruction):
1729         * bytecode/PutByIdFlags.cpp: Added.
1730         (WTF::printInternal):
1731         * bytecode/PutByIdFlags.h: Added.
1732         * bytecode/PutByIdStatus.cpp:
1733         (JSC::PutByIdStatus::computeFromLLInt):
1734         * bytecode/UnlinkedCodeBlock.h:
1735         (JSC::UnlinkedInstruction::UnlinkedInstruction):
1736         * bytecompiler/BytecodeGenerator.cpp:
1737         (JSC::BytecodeGenerator::emitPutById):
1738         (JSC::BytecodeGenerator::emitDirectPutById):
1739         * dfg/DFGByteCodeParser.cpp:
1740         (JSC::DFG::ByteCodeParser::parseBlock):
1741         * dfg/DFGCapabilities.cpp:
1742         (JSC::DFG::capabilityLevel):
1743         * jit/JIT.cpp:
1744         (JSC::JIT::privateCompileMainPass):
1745         (JSC::JIT::privateCompileSlowCases):
1746         * jit/JITPropertyAccess.cpp:
1747         (JSC::JIT::emit_op_put_by_id):
1748         * jit/JITPropertyAccess32_64.cpp:
1749         (JSC::JIT::emit_op_put_by_id):
1750         * llint/LLIntSlowPaths.cpp:
1751         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1752         * llint/LowLevelInterpreter32_64.asm:
1753         * llint/LowLevelInterpreter64.asm:
1754
1755 2015-09-14  Commit Queue  <commit-queue@webkit.org>
1756
1757         Unreviewed, rolling out r189751, r189752, and r189754.
1758         https://bugs.webkit.org/show_bug.cgi?id=149143
1759
1760         caused crashes everywhere (Requested by alexchristensen on
1761         #webkit).
1762
1763         Reverted changesets:
1764
1765         "LLInt get/put inline caches shouldn't use tons of opcodes"
1766         https://bugs.webkit.org/show_bug.cgi?id=149106
1767         http://trac.webkit.org/changeset/189751
1768
1769         "Unreviewed, fix non-x86 LLInt build."
1770         http://trac.webkit.org/changeset/189752
1771
1772         "Unreviewed, really fix non-x86 LLInt build without also
1773         breaking everything else."
1774         http://trac.webkit.org/changeset/189754
1775
1776 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
1777
1778         Unreviewed, really fix non-x86 LLInt build without also breaking everything else.
1779
1780         * llint/LowLevelInterpreter64.asm:
1781
1782 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
1783
1784         Unreviewed, fix non-x86 LLInt build.
1785
1786         * llint/LowLevelInterpreter64.asm:
1787
1788 2015-09-13  Filip Pizlo  <fpizlo@apple.com>
1789
1790         LLInt get/put inline caches shouldn't use tons of opcodes
1791         https://bugs.webkit.org/show_bug.cgi?id=149106
1792
1793         Reviewed by Geoffrey Garen.
1794
1795         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
1796         example, instead of having get_by_id branch on the kind of offset (inline or
1797         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
1798         But the problem with this approach is that it doesn't scale. In the property type
1799         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
1800         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
1801         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
1802         checks, we'd have 6 * 11 = 66 variants of put_by_id).
1803
1804         So, this patch completely changes the strategy to mostly using branching inside the
1805         opcode implementation. It's unlikely to have a performance effect. For example, the long
1806         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
1807         and yet nobody noticed. The regression was because the inline cache was in terms of the
1808         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
1809         didn't notice that, then we probably won't notice a couple new branches. (Also, this
1810         patch fixes that regression - the code no longer does such lookups except in the one
1811         unavoidable case in put_by_id transition chain checking.)
1812
1813         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
1814         this flags field to encode the desired type check in bug 148610.
1815
1816         This patch has no effect on performance according to run-jsc-benchmarks.
1817
1818         * CMakeLists.txt:
1819         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1820         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1821         * JavaScriptCore.xcodeproj/project.pbxproj:
1822         * bytecode/BytecodeList.json:
1823         * bytecode/BytecodeUseDef.h:
1824         (JSC::computeUsesForBytecodeOffset):
1825         (JSC::computeDefsForBytecodeOffset):
1826         * bytecode/CodeBlock.cpp:
1827         (JSC::CodeBlock::printGetByIdOp):
1828         (JSC::CodeBlock::printGetByIdCacheStatus):
1829         (JSC::CodeBlock::printPutByIdCacheStatus):
1830         (JSC::CodeBlock::dumpBytecode):
1831         (JSC::CodeBlock::CodeBlock):
1832         (JSC::CodeBlock::propagateTransitions):
1833         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1834         * bytecode/CodeBlock.h:
1835         * bytecode/GetByIdStatus.cpp:
1836         (JSC::GetByIdStatus::computeFromLLInt):
1837         * bytecode/Instruction.h:
1838         (JSC::Instruction::Instruction):
1839         * bytecode/PutByIdFlags.cpp: Added.
1840         (WTF::printInternal):
1841         * bytecode/PutByIdFlags.h: Added.
1842         * bytecode/PutByIdStatus.cpp:
1843         (JSC::PutByIdStatus::computeFromLLInt):
1844         * bytecode/UnlinkedCodeBlock.h:
1845         (JSC::UnlinkedInstruction::UnlinkedInstruction):
1846         * bytecompiler/BytecodeGenerator.cpp:
1847         (JSC::BytecodeGenerator::emitPutById):
1848         (JSC::BytecodeGenerator::emitDirectPutById):
1849         * dfg/DFGAbstractInterpreterInlines.h:
1850         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1851         * dfg/DFGByteCodeParser.cpp:
1852         (JSC::DFG::ByteCodeParser::parseBlock):
1853         * dfg/DFGCapabilities.cpp:
1854         (JSC::DFG::capabilityLevel):
1855         * jit/JIT.cpp:
1856         (JSC::JIT::privateCompileMainPass):
1857         (JSC::JIT::privateCompileSlowCases):
1858         * jit/JITPropertyAccess.cpp:
1859         (JSC::JIT::emit_op_put_by_id):
1860         * jit/JITPropertyAccess32_64.cpp:
1861         (JSC::JIT::emit_op_put_by_id):
1862         * llint/LLIntSlowPaths.cpp:
1863         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1864         * llint/LowLevelInterpreter32_64.asm:
1865         * llint/LowLevelInterpreter64.asm:
1866
1867 2015-09-14  Alex Christensen  <achristensen@webkit.org>
1868
1869         Progress towards CMake on Mac.
1870         https://bugs.webkit.org/show_bug.cgi?id=149123
1871
1872         Reviewed by Chris Dumez.
1873
1874         * CMakeLists.txt:
1875         Make forwarding headers for the replay subdirectory.
1876         * PlatformMac.cmake:
1877         Make forwarding headers for the generated inspector headers. 
1878         They should eventually either be packaged correctly with JavaScriptCore headers and included correctly.
1879
1880 2015-09-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1881
1882         [ES6] Cache the resolution result in JSModuleRecord
1883         https://bugs.webkit.org/show_bug.cgi?id=148896
1884
1885         Reviewed by Saam Barati.
1886
1887         The resolveExport operation is frequently called. For example,
1888         1. When instantiating the module environment, we call it for each exported name and imported
1889            name.
1890         2. When linking the imported module environment to the code block, we call it to resolve the
1891            resolution.
1892         3. When looking up the property from the namespace object, we call it to look up the original
1893            module for the imported binding.
1894         4. When creating the namespace object, we need to collect all the exported names from the module
1895            and need to resolve them by calling resolveExport.
1896
1897         However, resolveExport takes some cost. It traces the imported modules and resolves the reference
1898         queried by the original module.
1899
1900         The resolveExport operation is pure function; given a module record and an export name,
1901         it always returns the same result. So we cache resolution results in the module record to avoid
1902         repeated resolveExport calls with the same arguments.
1903         Here, we only cache the correctly resolved references, since,
1904         1. We rarely looked up the non-correctly-resolved ones. In the linking phase, attempting to
1905            resolve non-correctly-resolved ones throws a syntax error. So only namespace object creation
1906            phase does it in a syntax valid script.
1907         2. This strategy limits the size of the cache map. The number of the correctly exported bindings
1908            is defined by the modules' code. So the size does not become infinitely large.
1909
1910         Currently, the all modules cannot be linked twice. For example,
1911
1912           graph 1
1913
1914           -> (A) -> (B)
1915
1916           graph 2
1917
1918           -> (C) -> (A) -> (B)
1919
1920         We cannot test the behavior now because when executing the graph 2, (A) and (B) are already linked,
1921         it raises an error in the current loader spec. But it should be allowed[1] since it will occur when
1922         there is multiple module tag in WebCore.
1923
1924         [1]: https://github.com/whatwg/loader/issues/41
1925
1926         * runtime/JSModuleRecord.cpp:
1927         (JSC::JSModuleRecord::ResolveQuery::Hash::hash):
1928         (JSC::JSModuleRecord::ResolveQuery::Hash::equal):
1929         (JSC::JSModuleRecord::cacheResolution):
1930         (JSC::ResolveQueryHash::hash): Deleted.
1931         (JSC::ResolveQueryHash::equal): Deleted.
1932         (JSC::resolveExportLoop): Deleted.
1933         * runtime/JSModuleRecord.h:
1934         * tests/modules/caching-should-not-make-ambiguous.js: Added.
1935         * tests/modules/caching-should-not-make-ambiguous/A.js: Added.
1936         * tests/modules/caching-should-not-make-ambiguous/B.js: Added.
1937         * tests/modules/caching-should-not-make-ambiguous/C.js: Added.
1938         * tests/modules/caching-should-not-make-ambiguous/D.js: Added.
1939         * tests/modules/caching-should-not-make-ambiguous/main.js: Added.
1940         * tests/modules/different-view.js: Added.
1941         (from.string_appeared_here.shouldThrow):
1942         * tests/modules/different-view/A.js: Added.
1943         * tests/modules/different-view/B.js: Added.
1944         * tests/modules/different-view/C.js: Added.
1945         * tests/modules/different-view/D.js: Added.
1946         * tests/modules/different-view/E.js: Added.
1947         * tests/modules/different-view/main.js: Added.
1948         * tests/modules/fallback-ambiguous.js: Added.
1949         (from.string_appeared_here.shouldThrow):
1950         * tests/modules/fallback-ambiguous/A.js: Added.
1951         * tests/modules/fallback-ambiguous/B.js: Added.
1952         * tests/modules/fallback-ambiguous/C.js: Added.
1953         * tests/modules/fallback-ambiguous/D.js: Added.
1954         * tests/modules/fallback-ambiguous/E.js: Added.
1955         * tests/modules/fallback-ambiguous/main.js: Added.
1956         * tests/modules/self-star-link.js: Added.
1957         * tests/modules/self-star-link/A.js: Added.
1958         * tests/modules/self-star-link/B.js: Added.
1959         * tests/modules/self-star-link/C.js: Added.
1960         * tests/modules/self-star-link/D.js: Added.
1961         * tests/modules/self-star-link/E.js: Added.
1962         * tests/modules/uncacheable-when-see-star.js: Added.
1963         * tests/modules/uncacheable-when-see-star/A-pre.js: Added.
1964         * tests/modules/uncacheable-when-see-star/A.js: Added.
1965         * tests/modules/uncacheable-when-see-star/B.js: Added.
1966         * tests/modules/uncacheable-when-see-star/C.js: Added.
1967         * tests/modules/uncacheable-when-see-star/D.js: Added.
1968         * tests/modules/uncacheable-when-see-star/E-pre.js: Added.
1969         * tests/modules/uncacheable-when-see-star/E.js: Added.
1970         * tests/modules/uncacheable-when-see-star/main1.js: Added.
1971         * tests/modules/uncacheable-when-see-star/main2.js: Added.
1972
1973 2015-09-14  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1974
1975         Implement the arithmetic instructions for floats in WebAssembly
1976         https://bugs.webkit.org/show_bug.cgi?id=149102
1977
1978         Reviewed by Geoffrey Garen.
1979
1980         This patch implements the arithmetic instructions for floats (float32)
1981         in WebAssembly by converting the float operands to doubles, performing
1982         the equivalent double instructions, and converting the result back to
1983         float. The asm.js spec says that "As proved in 'When is double rounding
1984         innocuous?' (Figueroa 1995), both the 32- and 64-bit versions of
1985         standard arithmetic operations produce equivalent results when given
1986         32-bit inputs and coerced to 32-bit outputs."
1987         (http://asmjs.org/spec/latest/#floatish)
1988
1989         This patch also pads WebAssembly call frames by maxFrameExtentForSlowPathCall,
1990         so that there is no need to adjust the stack pointer every time we make
1991         a slow path call.
1992
1993         * tests/stress/wasm-arithmetic-float32.js:
1994         * tests/stress/wasm/arithmetic-float32.wasm:
1995         * wasm/WASMFunctionCompiler.h:
1996         (JSC::WASMFunctionCompiler::startFunction):
1997         (JSC::WASMFunctionCompiler::buildUnaryF32):
1998         (JSC::WASMFunctionCompiler::buildBinaryF32):
1999         (JSC::WASMFunctionCompiler::callOperation):
2000         (JSC::WASMFunctionCompiler::callAndUnboxResult):
2001         (JSC::WASMFunctionCompiler::endFunction): Deleted.
2002         (JSC::WASMFunctionCompiler::buildBinaryI32): Deleted.
2003         * wasm/WASMFunctionParser.cpp:
2004         (JSC::WASMFunctionParser::parseExpressionF32):
2005         (JSC::WASMFunctionParser::parseUnaryExpressionF32):
2006         (JSC::WASMFunctionParser::parseBinaryExpressionF32):
2007         * wasm/WASMFunctionParser.h:
2008         * wasm/WASMFunctionSyntaxChecker.h:
2009         (JSC::WASMFunctionSyntaxChecker::buildUnaryF32):
2010         (JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
2011
2012 2015-09-13  Geoffrey Garen  <ggaren@apple.com>
2013
2014         Eden GC should not try to jettison old CodeBlocks in the remembered set
2015         https://bugs.webkit.org/show_bug.cgi?id=149108
2016
2017         Reviewed by Saam Barati.
2018
2019         All we know about objects in the remembered set is that they must be
2020         visited. We don't know whether they're referenced or not because we
2021         won't mark the objects that point to them.
2022
2023         Therefore, it's incorrect for a CodeBlock to consider jettisoning
2024         itself when it's marked as a part of the remembered set: Some
2025         old object might have visited the CodeBlock strongly if given the chance.
2026
2027         I believe this doesn't cause any problems currently because we happen
2028         to visit all strong references to all CodeBlocks elligible for jettison
2029         during every GC.
2030
2031         However, this behavior is a logical oddity that tripped me up, and I
2032         believe it will start causing real problems once we start to jettison
2033         baseline CodeBlocks, since we do not visit all strong references to all
2034         baseline CodeBlocks during every GC.
2035
2036         * heap/CodeBlockSet.cpp:
2037         (JSC::CodeBlockSet::clearMarksForEdenCollection):
2038         (JSC::CodeBlockSet::traceMarked): Be sure to visit the remembered set
2039         strongly, in order to prohibit jettisoning.
2040
2041         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
2042         * heap/CodeBlockSet.h: Track the remembered set during eden GCs.
2043
2044 2015-09-11  Filip Pizlo  <fpizlo@apple.com>
2045
2046         REGRESSION(r189585): run-perf-tests Speedometer fails with a console error
2047         https://bugs.webkit.org/show_bug.cgi?id=149066
2048
2049         Reviewed by Michael Saboff.
2050
2051         The bug here was that the new IC code was calling actionForCell() more than once. That's
2052         illegal, since when actionForCell() returns RetryCacheLater, it means that it changed some
2053         object's Structure. The Repatch code was doing things like "if (actionForCell(blah) ==
2054         AttemptToCache)" in more than one place, so that if the first such expression was false, then
2055         we'd fall through to the next one. It's possible for the first call to return RetryCacheLater,
2056         in which case our view of the world just got clobbered and we need to return, and then the
2057         second call will probably return AttemptToCache because it *thinks* that we had bailed the last
2058         time and we're now in a future IC invocation.
2059
2060         The solution is to cache the actionForCell() result. This is a bit tricky, because we need to
2061         do this after we check if we're in a proxy.
2062
2063         Debugging bugs like these requires adding ad hoc bisection code in various places. We already
2064         had the basic hooks for this. This patch makes those hooks a bit more useful. In the case of
2065         the LLInt->JIT tier-up hooks, it adds a CodeBlock* argument so that we can bisect based on the
2066         CodeBlock. In the case of Repatch, it puts the Options::forceICFailure() check in a helper
2067         function that also takes ExecState*, which allows us to bisect on either CodeBlock or
2068         CodeOrigin.
2069
2070         * jit/Repatch.cpp:
2071         (JSC::actionForCell):
2072         (JSC::forceICFailure):
2073         (JSC::tryCacheGetByID):
2074         (JSC::tryCachePutByID):
2075         (JSC::tryRepatchIn):
2076         * llint/LLIntSlowPaths.cpp:
2077         (JSC::LLInt::shouldJIT):
2078         (JSC::LLInt::jitCompileAndSetHeuristics):
2079         (JSC::LLInt::entryOSR):
2080         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2081         * tests/stress/retry-cache-later.js:
2082
2083 2015-09-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2084
2085         Implement the relational instructions for floats in WebAssembly
2086         https://bugs.webkit.org/show_bug.cgi?id=149080
2087
2088         Reviewed by Geoffrey Garen.
2089
2090         This patch implements the relational instructions for floats (float32)
2091         in WebAssembly by converting float operands to doubles and then
2092         comparing them using the existing double comparison instructions in the
2093         macro assembler.
2094
2095         * tests/stress/wasm-relational.js:
2096         * tests/stress/wasm/relational.wasm:
2097         * wasm/WASMFunctionCompiler.h:
2098         (JSC::WASMFunctionCompiler::buildRelationalF32):
2099         * wasm/WASMFunctionParser.cpp:
2100         (JSC::WASMFunctionParser::parseExpressionI32):
2101         (JSC::WASMFunctionParser::parseRelationalF32ExpressionI32):
2102         * wasm/WASMFunctionParser.h:
2103         * wasm/WASMFunctionSyntaxChecker.h:
2104         (JSC::WASMFunctionSyntaxChecker::buildRelationalF32):
2105
2106 2015-09-11  Nan Wang  <n_wang@apple.com>
2107
2108         AX: ARIA 1.1 @aria-current
2109         https://bugs.webkit.org/show_bug.cgi?id=146012
2110
2111         Reviewed by Chris Fleizach.
2112
2113         Updated inspector to support aria-current.
2114
2115         * inspector/protocol/DOM.json:
2116
2117 2015-09-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2118
2119         Add initial support for floats in WebAsssembly
2120         https://bugs.webkit.org/show_bug.cgi?id=149062
2121
2122         Reviewed by Geoffrey Garen.
2123
2124         Implement the ConstantPoolIndex, Immediate, GetLocal, and GetGlobal
2125         instructions for floats (float32) in WebAssembly.
2126
2127         * tests/stress/wasm-arithmetic-float32.js: Added.
2128         (shouldBe):
2129         * tests/stress/wasm-globals.js:
2130         * tests/stress/wasm-type-conversion.js:
2131         * tests/stress/wasm/arithmetic-float32.wasm: Added.
2132         * tests/stress/wasm/globals.wasm:
2133         * tests/stress/wasm/type-conversion.wasm:
2134         * wasm/WASMConstants.h:
2135         * wasm/WASMFunctionCompiler.h:
2136         (JSC::WASMFunctionCompiler::buildSetLocal):
2137         (JSC::WASMFunctionCompiler::buildReturn):
2138         (JSC::WASMFunctionCompiler::buildImmediateF32):
2139         (JSC::WASMFunctionCompiler::buildGetLocal):
2140         * wasm/WASMFunctionParser.cpp:
2141         (JSC::WASMFunctionParser::parseExpression):
2142         (JSC::WASMFunctionParser::parseExpressionF32):
2143         (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF32):
2144         (JSC::WASMFunctionParser::parseImmediateExpressionF32):
2145         (JSC::WASMFunctionParser::parseGetLocalExpressionF32):
2146         (JSC::WASMFunctionParser::parseGetGlobalExpressionF32):
2147         * wasm/WASMFunctionParser.h:
2148         * wasm/WASMFunctionSyntaxChecker.h:
2149         (JSC::WASMFunctionSyntaxChecker::buildImmediateF32):
2150         * wasm/WASMReader.cpp:
2151         (JSC::WASMReader::readOpExpressionF32):
2152         * wasm/WASMReader.h:
2153
2154 2015-09-11  Geoffrey Garen  <ggaren@apple.com>
2155
2156         Try to fix the CLOOP build.
2157
2158         Unreviewed.
2159
2160         * bytecode/CodeBlock.cpp:
2161         (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
2162         (JSC::CodeBlock::finalizeUnconditionally):
2163
2164 2015-09-11  Csaba Osztrogon√°c  <ossy@webkit.org>
2165
2166         [EFL] Fix WASM build
2167         https://bugs.webkit.org/show_bug.cgi?id=149065
2168
2169         Reviewed by Darin Adler.
2170
2171         * wasm/WASMFunctionParser.cpp:
2172
2173 2015-09-11  Geoffrey Garen  <ggaren@apple.com>
2174
2175         JavaScriptCore should discard optimized code after some time
2176         https://bugs.webkit.org/show_bug.cgi?id=149048
2177
2178         Reviewed by Michael Saboff.
2179
2180         This patch adds a new jettison type -- JettisonDueToOldAge -- and starts
2181         using it for DFG and FTL code. Baseline and LLInt code will come in a
2182         follow-up patch.
2183
2184         The primary goal is to save memory. Some popular websites leave about 10MB
2185         of dead code sitting around immediately after they finish loading.
2186
2187         Throwing away code periodically might also save us from profiling
2188         pathologies that lead to performance dead ends.
2189
2190         * bytecode/CodeBlock.cpp:
2191         (JSC::CodeBlock::visitAggregate): Updated for rename, and removed a
2192         stale comment.
2193
2194         (JSC::CodeBlock::shouldVisitStrongly): Renamed to shouldVisitStrongly
2195         because the practical effect of this function is to trigger a call to
2196         visitStrongly.
2197
2198         (JSC::CodeBlock::isKnownToBeLiveDuringGC): Check the
2199         m_visitStronglyHasBeenCalled flag instead of
2200         shouldImmediatelyAssumeLivenessDuringScan / shouldVisitStrongly because
2201         m_visitStronglyHasBeenCalled can be set by anybody even if the CodeBlock
2202         would not otherwise visit itself strongly.
2203
2204         (JSC::CodeBlock::shouldJettisonDueToWeakReference): New helper function
2205         for readability.
2206
2207         (JSC::CodeBlock::shouldJettisonDueToOldAge): New helper function that
2208         tells if a CodeBlock is old enough for deletion.
2209
2210         (JSC::CodeBlock::determineLiveness): There's no need to check
2211         shouldImmediatelyAssumeLivenessDuringScan here because we will not call
2212         this function if shouldImmediatelyAssumeLivenessDuringScan is true.
2213         Also, it's just not clear -- if someone chooses to call this function --
2214         that it would be safe to ignore them simply because
2215         shouldImmediatelyAssumeLivenessDuringScan was true.
2216
2217         (JSC::CodeBlock::finalizeLLIntInlineCaches): Moved code out into a helper
2218         function to make the main function more readable.
2219
2220         (JSC::CodeBlock::finalizeBaselineJITInlineCaches): Ditto.
2221
2222         (JSC::CodeBlock::finalizeUnconditionally): Added code for jettisoning a
2223         CodeBlock if it is too old. Moved large sections of code into helper
2224         functions to aid readability in this function.
2225
2226         (JSC::CodeBlock::jettison): Account for the fact that we might jettison
2227         a CodeBlock without OSR exit and without requiring a stack shoot-down.
2228
2229         * bytecode/CodeBlock.h:
2230         (JSC::CodeBlock::setInstallTime):
2231         (JSC::CodeBlock::timeSinceInstall): Track CodeBlock age to help us
2232         decide when to delete.
2233
2234         * jit/JITCode.h:
2235         (JSC::JITCode::timeToLive): Static limits on CodeBlock lifetime. I got
2236         these numbers from the place where numbers come from. 
2237
2238         * profiler/ProfilerJettisonReason.cpp:
2239         (WTF::printInternal):
2240         * profiler/ProfilerJettisonReason.h: Updated for new jettison type.
2241
2242         * runtime/Executable.cpp:
2243         (JSC::ScriptExecutable::installCode): Record install time so that we
2244         can measure how old a CodeBlock is.
2245
2246 2015-09-11  Andreas Kling  <akling@apple.com>
2247
2248         [JSC] Weak should only accept cell pointees.
2249         <https://webkit.org/b/148955>
2250
2251         Reviewed by Geoffrey Garen.
2252
2253         Since WeakImpls only support pointing to JSCell derived objects,
2254         enforce that at compile time by having the API use JSCell* instead of JSValue.
2255
2256         WeakHandleOwner callbacks now get JSCell& and JSCell*& respectively instead
2257         of wrapping the cell pointer in a Handle<Unknown>.
2258
2259         Also added a static_assert so Weak<T> can't be instantiated with a T that's
2260         not convertible to JSCell.
2261
2262         * API/JSAPIWrapperObject.mm:
2263         (JSAPIWrapperObjectHandleOwner::finalize):
2264         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
2265         (JSC::JSAPIWrapperObject::finishCreation):
2266         * API/JSManagedValue.mm:
2267         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
2268         (JSManagedValueHandleOwner::finalize):
2269         * builtins/BuiltinExecutables.cpp:
2270         (JSC::BuiltinExecutables::finalize):
2271         * builtins/BuiltinExecutables.h:
2272         * heap/Heap.cpp:
2273         (JSC::Heap::addFinalizer):
2274         (JSC::Heap::FinalizerOwner::finalize):
2275         * heap/Heap.h:
2276         * heap/WeakBlock.cpp:
2277         (JSC::WeakBlock::visit):
2278         (JSC::WeakBlock::reap):
2279         * heap/WeakHandleOwner.cpp:
2280         (JSC::WeakHandleOwner::isReachableFromOpaqueRoots):
2281         (JSC::WeakHandleOwner::finalize):
2282         * heap/WeakHandleOwner.h:
2283         * heap/WeakImpl.h:
2284         (JSC::WeakImpl::WeakImpl):
2285         (JSC::WeakImpl::state):
2286         (JSC::WeakImpl::cell):
2287         (JSC::WeakImpl::asWeakImpl):
2288         (JSC::WeakImpl::jsValue): Deleted.
2289         * heap/WeakInlines.h:
2290         (JSC::Weak<T>::Weak):
2291         (JSC::>):
2292         (JSC::Weak<T>::operator):
2293         (JSC::Weak<T>::get):
2294         (JSC::Weak<T>::was):
2295         * heap/WeakSet.h:
2296         * heap/WeakSetInlines.h:
2297         (JSC::WeakSet::allocate):
2298         (JSC::WeakBlock::finalize):
2299         * jit/JITThunks.cpp:
2300         (JSC::JITThunks::finalize):
2301         * jit/JITThunks.h:
2302         * jsc.cpp:
2303         (WTF::ElementHandleOwner::isReachableFromOpaqueRoots): Deleted.
2304         * runtime/JSCell.h:
2305         (JSC::jsCast):
2306         * runtime/RegExpCache.cpp:
2307         (JSC::RegExpCache::finalize):
2308         * runtime/RegExpCache.h:
2309         * runtime/Structure.cpp:
2310         (JSC::StructureTransitionTable::singleTransition):
2311         (JSC::StructureTransitionTable::setSingleTransition):
2312
2313 2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2314
2315         Implement switch statements in WebAssembly
2316         https://bugs.webkit.org/show_bug.cgi?id=149051
2317
2318         Reviewed by Geoffrey Garen.
2319
2320         This patch implements switch statements in WebAssembly using the
2321         JSC::BinarySwitch class.
2322
2323         * tests/stress/wasm-control-flow.js:
2324         * tests/stress/wasm/control-flow.wasm:
2325         * wasm/WASMFunctionCompiler.h:
2326         (JSC::WASMFunctionCompiler::buildSwitch):
2327         * wasm/WASMFunctionParser.cpp:
2328         (JSC::WASMFunctionParser::parseSwitchStatement):
2329         * wasm/WASMFunctionSyntaxChecker.h:
2330         (JSC::WASMFunctionSyntaxChecker::buildSwitch):
2331
2332 2015-09-10  Filip Pizlo  <fpizlo@apple.com>
2333
2334         Structure should be able to tell you if it had ever been a dictionary
2335         https://bugs.webkit.org/show_bug.cgi?id=149047
2336
2337         Reviewed by Mark Lam.
2338
2339         Introduces the hasBeenDictionary flag to Structure, which tells you if this structure or
2340         any of its ancestors is a dictionary. We already implicitly tracked this for DFG
2341         watchpoint optimizations, so this is mainly just decoupling that existing logic from
2342         watchpoints. Having Structure::hasBeenDictionary() enables some of the heuristics in the
2343         property type inference work (https://bugs.webkit.org/show_bug.cgi?id=148610).
2344
2345         * runtime/Structure.cpp:
2346         (JSC::Structure::Structure):
2347         (JSC::Structure::toDictionaryTransition):
2348         (JSC::Structure::dump):
2349         * runtime/Structure.h:
2350
2351 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2352
2353         Unreviewed, fix Windows file loading in JSC shell after r189583
2354         https://bugs.webkit.org/show_bug.cgi?id=148917
2355
2356         Should load the script files with the binary mode.
2357         Since these loading functions are only used for the simple test scripts,
2358         we just use ftell / fseek now.
2359
2360         * jsc.cpp:
2361         (fillBufferWithContentsOfFile):
2362
2363 2015-09-10  Michael Saboff  <msaboff@apple.com>
2364
2365         REGRESSION(r189575): Appears to break ARM64 linux builds
2366         https://bugs.webkit.org/show_bug.cgi?id=149044
2367
2368         Reviewed by Filip Pizlo.
2369
2370         Changed the use of the ARM64 "fp", a register alias, to be "x29", the real register name.
2371
2372         * llint/LowLevelInterpreter.asm:
2373
2374 2015-09-09  Filip Pizlo  <fpizlo@apple.com>
2375
2376         There should be one stub hanging off an inline cache that contains code for all of the cases, rather than forming a linked list consisting of one stub per case
2377         https://bugs.webkit.org/show_bug.cgi?id=148717
2378
2379         Reviewed by Michael Saboff.
2380
2381         This is a major rewrite of the JSC get/put/in inline caches (ICs), motivated by the need to add
2382         fancy new kinds of inline caches for property type inference (https://webkit.org/b/148610).
2383
2384         Previously, our inline caches had some problems that made them difficult to work with. It was
2385         impossible to change any code that was previously generated by the IC except by blowing the
2386         whole IC away, the ICs scaled poorly if there were many cases, and there was a lot of duplicate
2387         and ad hoc code.
2388
2389         Impossible to regenerate a previously generated stub: Say that some access (o.f = v) causes our
2390         IC code to emit some stub; let's call it stub1. Then later we find that we need to emit a
2391         different stub, stub2, where we think that stub2 might subsume stub1. We say that stub2
2392         subsumes stub1 if failing to execute stub2 to completion means that we are guaranteed to fail
2393         to execute stub1 to completion. This could happen in trunk if stub2 has the same base structure
2394         as stub1 but different prototype conditions. It could happen with property type inference if
2395         stub2 has a looser type check on v than stub1 did. Currently, if this happened, we would emit
2396         stub2 and have its slow path jump to stub1. Hence, we would still end up executing the checks
2397         of stub1 before falling through to the slow path. This gets bad when there are many stubs.
2398         Stub1 might be in front of a bunch of other stubs, so when we add stub2, we will end up
2399         executing both stub2's and stub1's checks before falling through to the other stubs. It would
2400         be better if we could remove stub1 from the list at this point. But since stub1 could be linked
2401         to from a different stub that we had already generated, we'd have to have a way of patching
2402         stubs or regenerating them from scratch. This is currenty impossible because we just don't keep
2403         around enough meta-data to mess with a stub after it's generated. After this change, we never
2404         link new stubs onto a linked list of pre-existing stubs; instead each IC will have one stub
2405         hanging off of it and we always regenerate that one stub from scratch. That one stub contains
2406         either a BinarySwitch or a branch cascade to select one of the AccessCases. Each AccessCase is
2407         an object that describes everything we need to regenerate it in the future. This means that
2408         when we add a new case to an IC stub, we can figure out which previous cases this one subsumes.
2409
2410         Poor scalability when there are many cases: Previously, the cases of a polymorphic inline cache
2411         formed a linked list of branches. This meant that the complexity of an inline cache grew
2412         linearly with the number of cases. This change turns this into a BinarySwitch in most cases,
2413         leading to logarithmic scaling.
2414
2415         Duplicate code between get, put, and in: The code for op_get_by_id, op_put_by_id, and op_in
2416         inline caches grew independently and ended up having a lot of duplicate code. We had the worst
2417         kinds of duplicate code. In some cases, the code was copy-pasted. In other cases, we wrote code
2418         that felt like it was new despite the fact that it was logically identical to code that was
2419         already written elsewhere. The main sources of duplication were in selecting a scratch
2420         register, checking all of the ObjectPropertyConditions and the base structure, the pro forma
2421         involved in generating a stub, and the data structures needed to describe all of the access
2422         cases. This change deduplicates all of that code. Now, all of those ICs use the same classes:
2423         the PolymorphicAccess and AccessCase. There is code in those classes that handles all of the
2424         common things, and for the most part the only code that actually specializes for the kind of
2425         access is in some switch statement in AccessCase::generate().
2426
2427         Special-casing of array length and string length: Previously, array.length and string.length
2428         were handled in an ad hoc manner in the get_by_id repatching code. The handling was separate
2429         from the polymorphic get_by_id handling, which meant that we could not handle polymorphic
2430         length accesses if one of the length cases was either array or string length. For example, if
2431         you had "o.length" where the length was either array length or a vanilla length property, then
2432         the get_by_id inline cache would either emit a monomorphic stub for array length, or a
2433         monomorphic stub for the vanilla length property, but never a polymorphic stub (or list) that
2434         could do both. This change addresses this problem by folding array length and string length
2435         into the polymorphic get_by_id code.
2436
2437         This was meant to be a perf-neutral change to enable property type inference, but it ended up
2438         being a 1% Octane speed-up, mainly because of a 14% speed-up in raytrace. This isn't too
2439         surprising, since that test does use inline caches a lot and this change makes inline caches
2440         more scalable.
2441
2442         This also fixes and adds a test for a BinarySwitch bug. BinarySwitch had an optimization for
2443         consecutive integer cases. Using it on typed array structures triggers this bug. It's a hard
2444         bug to trigger any other way because our other switch optimizations will usually use a jump
2445         table in case of consecutive integers.
2446
2447         * CMakeLists.txt:
2448         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2449         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2450         * JavaScriptCore.xcodeproj/project.pbxproj:
2451         * assembler/MacroAssemblerCodeRef.h:
2452         (JSC::MacroAssemblerCodePtr::dumpWithName):
2453         * bytecode/CodeBlock.cpp:
2454         (JSC::CodeBlock::printGetByIdCacheStatus):
2455         (JSC::CodeBlock::printPutByIdCacheStatus):
2456         (JSC::CodeBlock::propagateTransitions):
2457         (JSC::CodeBlock::getByValInfoMap):
2458         (JSC::CodeBlock::addStubInfo):
2459         (JSC::CodeBlock::findStubInfo):
2460         * bytecode/CodeBlock.h:
2461         (JSC::CodeBlock::stubInfoBegin):
2462         (JSC::CodeBlock::stubInfoEnd):
2463         * bytecode/GetByIdStatus.cpp:
2464         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2465         * bytecode/PolymorphicAccess.cpp: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp.
2466         (JSC::AccessGenerationState::addWatchpoint):
2467         (JSC::AccessGenerationState::restoreScratch):
2468         (JSC::AccessGenerationState::succeed):
2469         (JSC::AccessCase::AccessCase):
2470         (JSC::AccessCase::get):
2471         (JSC::AccessCase::replace):
2472         (JSC::AccessCase::transition):
2473         (JSC::AccessCase::setter):
2474         (JSC::AccessCase::in):
2475         (JSC::AccessCase::getLength):
2476         (JSC::AccessCase::~AccessCase):
2477         (JSC::AccessCase::fromStructureStubInfo):
2478         (JSC::AccessCase::clone):
2479         (JSC::AccessCase::guardedByStructureCheck):
2480         (JSC::AccessCase::alternateBase):
2481         (JSC::AccessCase::canReplace):
2482         (JSC::AccessCase::dump):
2483         (JSC::AccessCase::visitWeak):
2484         (JSC::AccessCase::generateWithGuard):
2485         (JSC::AccessCase::generate):
2486         (JSC::PolymorphicAccess::PolymorphicAccess):
2487         (JSC::PolymorphicAccess::~PolymorphicAccess):
2488         (JSC::PolymorphicAccess::regenerateWithCases):
2489         (JSC::PolymorphicAccess::regenerateWithCase):
2490         (JSC::PolymorphicAccess::visitWeak):
2491         (JSC::PolymorphicAccess::dump):
2492         (JSC::PolymorphicAccess::regenerate):
2493         (WTF::printInternal):
2494         (JSC::GetByIdAccess::GetByIdAccess): Deleted.
2495         (JSC::GetByIdAccess::~GetByIdAccess): Deleted.
2496         (JSC::GetByIdAccess::fromStructureStubInfo): Deleted.
2497         (JSC::GetByIdAccess::visitWeak): Deleted.
2498         (JSC::PolymorphicGetByIdList::PolymorphicGetByIdList): Deleted.
2499         (JSC::PolymorphicGetByIdList::from): Deleted.
2500         (JSC::PolymorphicGetByIdList::~PolymorphicGetByIdList): Deleted.
2501         (JSC::PolymorphicGetByIdList::currentSlowPathTarget): Deleted.
2502         (JSC::PolymorphicGetByIdList::addAccess): Deleted.
2503         (JSC::PolymorphicGetByIdList::isFull): Deleted.
2504         (JSC::PolymorphicGetByIdList::isAlmostFull): Deleted.
2505         (JSC::PolymorphicGetByIdList::didSelfPatching): Deleted.
2506         (JSC::PolymorphicGetByIdList::visitWeak): Deleted.
2507         * bytecode/PolymorphicAccess.h: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.h.
2508         (JSC::AccessCase::isGet):
2509         (JSC::AccessCase::isPut):
2510         (JSC::AccessCase::isIn):
2511         (JSC::AccessCase::type):
2512         (JSC::AccessCase::offset):
2513         (JSC::AccessCase::viaProxy):
2514         (JSC::AccessCase::structure):
2515         (JSC::AccessCase::newStructure):
2516         (JSC::AccessCase::conditionSet):
2517         (JSC::AccessCase::additionalSet):
2518         (JSC::AccessCase::customSlotBase):
2519         (JSC::AccessCase::doesCalls):
2520         (JSC::AccessCase::callLinkInfo):
2521         (JSC::AccessCase::RareData::RareData):
2522         (JSC::PolymorphicAccess::isEmpty):
2523         (JSC::PolymorphicAccess::size):
2524         (JSC::PolymorphicAccess::at):
2525         (JSC::PolymorphicAccess::operator[]):
2526         (JSC::GetByIdAccess::GetByIdAccess): Deleted.
2527         (JSC::GetByIdAccess::isSet): Deleted.
2528         (JSC::GetByIdAccess::operator!): Deleted.
2529         (JSC::GetByIdAccess::type): Deleted.
2530         (JSC::GetByIdAccess::structure): Deleted.
2531         (JSC::GetByIdAccess::conditionSet): Deleted.
2532         (JSC::GetByIdAccess::stubRoutine): Deleted.
2533         (JSC::GetByIdAccess::doesCalls): Deleted.
2534         (JSC::PolymorphicGetByIdList::isEmpty): Deleted.
2535         (JSC::PolymorphicGetByIdList::size): Deleted.
2536         (JSC::PolymorphicGetByIdList::at): Deleted.
2537         (JSC::PolymorphicGetByIdList::operator[]): Deleted.
2538         * bytecode/PolymorphicAccessStructureList.h: Removed.
2539         * bytecode/PolymorphicGetByIdList.cpp: Removed.
2540         * bytecode/PolymorphicGetByIdList.h: Removed.
2541         * bytecode/PolymorphicPutByIdList.cpp: Removed.
2542         * bytecode/PolymorphicPutByIdList.h: Removed.
2543         * bytecode/PutByIdStatus.cpp:
2544         (JSC::PutByIdStatus::computeForStubInfo):
2545         * bytecode/StructureStubInfo.cpp:
2546         (JSC::StructureStubInfo::deref):
2547         (JSC::StructureStubInfo::addAccessCase):
2548         (JSC::StructureStubInfo::reset):
2549         (JSC::StructureStubInfo::visitWeakReferences):
2550         * bytecode/StructureStubInfo.h:
2551         (JSC::StructureStubInfo::StructureStubInfo):
2552         (JSC::StructureStubInfo::initGetByIdSelf):
2553         (JSC::StructureStubInfo::initPutByIdReplace):
2554         (JSC::StructureStubInfo::initStub):
2555         (JSC::StructureStubInfo::setSeen):
2556         (JSC::getStructureStubInfoCodeOrigin):
2557         (JSC::isGetByIdAccess): Deleted.
2558         (JSC::isPutByIdAccess): Deleted.
2559         (JSC::isInAccess): Deleted.
2560         (JSC::StructureStubInfo::initGetByIdList): Deleted.
2561         (JSC::StructureStubInfo::initPutByIdTransition): Deleted.
2562         (JSC::StructureStubInfo::initPutByIdList): Deleted.
2563         (JSC::StructureStubInfo::initInList): Deleted.
2564         (JSC::StructureStubInfo::addWatchpoint): Deleted.
2565         * dfg/DFGSpeculativeJIT.cpp:
2566         (JSC::DFG::SpeculativeJIT::compileIn):
2567         * ftl/FTLCompile.cpp:
2568         (JSC::FTL::mmAllocateDataSection):
2569         * jit/AccessorCallJITStubRoutine.cpp: Removed.
2570         * jit/AccessorCallJITStubRoutine.h: Removed.
2571         * jit/AssemblyHelpers.h:
2572         (JSC::AssemblyHelpers::branchIfEmpty):
2573         (JSC::AssemblyHelpers::branchStructure):
2574         (JSC::AssemblyHelpers::boxBooleanPayload):
2575         (JSC::AssemblyHelpers::boxBoolean):
2576         (JSC::AssemblyHelpers::boxInt32):
2577         * jit/BinarySwitch.cpp:
2578         (JSC::BinarySwitch::BinarySwitch):
2579         (JSC::BinarySwitch::build):
2580         (JSC::BinarySwitch::Case::dump):
2581         (JSC::BinarySwitch::BranchCode::dump):
2582         * jit/BinarySwitch.h:
2583         (JSC::BinarySwitch::Case::operator<):
2584         (JSC::BinarySwitch::BranchCode::BranchCode):
2585         * jit/JIT.h:
2586         * jit/JITInlineCacheGenerator.cpp:
2587         (JSC::garbageStubInfo):
2588         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
2589         (JSC::JITByIdGenerator::JITByIdGenerator):
2590         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2591         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2592         * jit/JITInlineCacheGenerator.h:
2593         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
2594         (JSC::JITInlineCacheGenerator::stubInfo):
2595         (JSC::JITByIdGenerator::JITByIdGenerator):
2596         (JSC::JITByIdGenerator::reportSlowPathCall):
2597         * jit/JITOperations.cpp:
2598         * jit/Repatch.cpp:
2599         (JSC::repatchCall):
2600         (JSC::repatchByIdSelfAccess):
2601         (JSC::resetGetByIDCheckAndLoad):
2602         (JSC::resetPutByIDCheckAndLoad):
2603         (JSC::replaceWithJump):
2604         (JSC::tryCacheGetByID):
2605         (JSC::repatchGetByID):
2606         (JSC::appropriateGenericPutByIdFunction):
2607         (JSC::appropriateOptimizingPutByIdFunction):
2608         (JSC::tryCachePutByID):
2609         (JSC::repatchPutByID):
2610         (JSC::tryRepatchIn):
2611         (JSC::repatchIn):
2612         (JSC::resetGetByID):
2613         (JSC::resetPutByID):
2614         (JSC::checkObjectPropertyCondition): Deleted.
2615         (JSC::checkObjectPropertyConditions): Deleted.
2616         (JSC::emitRestoreScratch): Deleted.
2617         (JSC::linkRestoreScratch): Deleted.
2618         (JSC::toString): Deleted.
2619         (JSC::kindFor): Deleted.
2620         (JSC::customFor): Deleted.
2621         (JSC::generateByIdStub): Deleted.
2622         (JSC::patchJumpToGetByIdStub): Deleted.
2623         (JSC::tryBuildGetByIDList): Deleted.
2624         (JSC::buildGetByIDList): Deleted.
2625         (JSC::appropriateListBuildingPutByIdFunction): Deleted.
2626         (JSC::emitPutReplaceStub): Deleted.
2627         (JSC::emitPutTransitionStub): Deleted.
2628         (JSC::tryBuildPutByIdList): Deleted.
2629         (JSC::buildPutByIdList): Deleted.
2630         * jit/ScratchRegisterAllocator.cpp:
2631         (JSC::ScratchRegisterAllocator::lock):
2632         (JSC::ScratchRegisterAllocator::allocateScratch):
2633         * jit/ScratchRegisterAllocator.h:
2634         (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator):
2635         * jsc.cpp:
2636         (GlobalObject::finishCreation):
2637         (functionQuit):
2638         (functionAbort):
2639         (functionFalse1):
2640         (functionFalse2):
2641         * runtime/Options.h:
2642         * tests/stress/array-message-passing.js: Added.
2643         (window.addEventListener):
2644         (window.postMessage):
2645         (window._handleEvents):
2646         (testPassed):
2647         (testFailed):
2648         (classCompare):
2649         (bufferCompare):
2650         (viewCompare):
2651         (typedArrayCompare):
2652         (dataViewCompare):
2653         (dataViewCompare2):
2654         (dataViewCompare3):
2655         (createBuffer):
2656         (createTypedArray):
2657         (createTypedArrayOverBuffer):
2658         (new.DataView):
2659         (testList.testList.concat.basicBufferTypes.map):
2660         (doneTest):
2661
2662 2015-09-10  Geoffrey Garen  <ggaren@apple.com>
2663
2664         CodeBlock::codeType() doesn't need to compute anything
2665         https://bugs.webkit.org/show_bug.cgi?id=149039
2666
2667         Reviewed by Michael Saboff.
2668
2669         CodeBlock already has an m_codeType data member.
2670
2671         * bytecode/CodeBlock.h:
2672         (JSC::CodeBlock::codeType):
2673         (JSC::CodeBlock::putByIdContext):
2674
2675 2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2676
2677         Implement global variables in WebAssembly
2678         https://bugs.webkit.org/show_bug.cgi?id=149031
2679
2680         Reviewed by Geoffrey Garen.
2681
2682         This patch implements global variables in WebAssembly. There are two
2683         types of global variables in the current format that we use (the format
2684         used by <https://github.com/WebAssembly/polyfill-prototype-1>): internal
2685         global variables and imported global variables. This patch does not yet
2686         import values for imported global variables. It will be done in a
2687         subsequent patch.
2688
2689         * tests/stress/wasm-globals.js: Added.
2690         (shouldBe):
2691         * tests/stress/wasm/globals.wasm: Added.
2692         * wasm/JSWASMModule.h:
2693         (JSC::JSWASMModule::globalVariables):
2694         * wasm/WASMFunctionCompiler.h:
2695         (JSC::WASMFunctionCompiler::buildSetGlobal):
2696         (JSC::WASMFunctionCompiler::buildGetGlobal):
2697         * wasm/WASMFunctionParser.cpp:
2698         (JSC::WASMFunctionParser::parseStatement):
2699         (JSC::WASMFunctionParser::parseSetGlobalStatement):
2700         (JSC::WASMFunctionParser::parseExpressionI32):
2701         (JSC::WASMFunctionParser::parseGetGlobalExpressionI32):
2702         (JSC::WASMFunctionParser::parseExpressionF64):
2703         (JSC::WASMFunctionParser::parseGetGlobalExpressionF64):
2704         * wasm/WASMFunctionParser.h:
2705         * wasm/WASMFunctionSyntaxChecker.h:
2706         (JSC::WASMFunctionSyntaxChecker::buildSetGlobal):
2707         (JSC::WASMFunctionSyntaxChecker::buildGetGlobal):
2708         * wasm/WASMModuleParser.cpp:
2709         (JSC::WASMModuleParser::parseGlobalSection):
2710
2711 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2712
2713         Consider long module path name case in Windows
2714         https://bugs.webkit.org/show_bug.cgi?id=148917
2715
2716         Reviewed by Alex Christensen.
2717
2718         The local file system module loader in the JSC shell manages the module files by the absolute path.
2719         However, in Windows, _MAX_PATH is defined as 260. So if the path like the current working directory or the path to the module is long,
2720         it will be truncated by the API and it fail to open the file.
2721         In JSC tests in Apple Windows buildbot, since the current working directory is long enough, the tests failed.
2722
2723         This patch introduces the following 3 tweaks.
2724
2725         1. When retrieving the current working path, we use GetCurrentDirectoryW instead of _getcwd.
2726            GetCurrentDirectoryW allows the long path while _getcwd automatically truncate the result by the _MAX_PATH.
2727
2728         2. Before opening the module file, we prepend "\\?\" to the path. It converts the local file path to the long UNC path
2729            which allows longer path names.
2730
2731         3. Since Windows ASCII API accepts the characters in the current code page, we use the Unicode APIs like _wfopen instead.
2732
2733         And enable the once disabled module tests in Windows.
2734
2735         Since this functionality is the part of the JSC shell to run the module tests, it is now implemented in jsc.cpp.
2736
2737         * jsc.cpp:
2738         (stringFromUTF):
2739         (jscSource):
2740         (extractDirectoryName):
2741         (currentWorkingDirectory):
2742         (convertShebangToJSComment):
2743         (fillBufferWithContentsOfFile):
2744         (fetchScriptFromLocalFileSystem):
2745         (fetchModuleFromLocalFileSystem):
2746         (GlobalObject::moduleLoaderFetch):
2747         (functionRun):
2748         (functionLoad):
2749         (functionReadFile):
2750         (functionCheckSyntax):
2751         (functionLoadModule):
2752         (runWithScripts):
2753         (runInteractive):
2754         * tests/modules.yaml:
2755
2756 2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2757
2758         Convert arguments to WebAssembly functions to the declared types
2759         https://bugs.webkit.org/show_bug.cgi?id=149033
2760
2761         Reviewed by Geoffrey Garen.
2762
2763         This patch checks the types of arguments to WebAssembly functions and
2764         converts them to the declared types. This is necessary because:
2765         - For example, if a function expects an argument of type double and we
2766           pass 1.0 to it, it will get a JSValue of an integer, not a double.
2767         - We should follow asm.js's behavior for now, because we want to be able
2768           to test WebAssembly apps against asm.js apps. asm.js does type
2769           coercion on arguments by using int|0, Math.fround(float), and +double.
2770
2771         * jit/JITOperations.h:
2772         * tests/stress/wasm-type-conversion.js: Added.
2773         (shouldBe):
2774         (two.valueOf):
2775         * tests/stress/wasm/type-conversion.wasm: Added.
2776         * wasm/WASMFunctionCompiler.h:
2777         (JSC::operationConvertJSValueToInt32):
2778         (JSC::operationConvertJSValueToDouble):
2779         (JSC::WASMFunctionCompiler::startFunction):
2780         (JSC::WASMFunctionCompiler::appendCallSetResult):
2781         (JSC::WASMFunctionCompiler::callOperation):
2782         (JSC::WASMFunctionCompiler::loadValueAndConvertToInt32):
2783         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):
2784
2785 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2786
2787         JSInternalPromiseDeferred should inherit JSPromiseDeferred
2788         https://bugs.webkit.org/show_bug.cgi?id=149027
2789
2790         Reviewed by Darin Adler.
2791
2792         JSInternalPromiseDeferred is constructed by using JSPromiseDeferred implementation.
2793         So the class info of JSInternalPromiseDeferred should inherit JSPromiseDeferred.
2794
2795         * runtime/JSInternalPromiseDeferred.cpp:
2796
2797 2015-09-10  Michael Saboff  <msaboff@apple.com>
2798
2799         Add support for Callee-Saves registers
2800         https://bugs.webkit.org/show_bug.cgi?id=148666
2801
2802         Reviewed by Filip Pizlo.
2803
2804         We save platform callee save registers right below the call frame header,
2805         in the location(s) starting with VirtualRegister 0.  This local space is
2806         allocated in the bytecode compiler.  This space is the maximum space
2807         needed for the callee registers that the LLInt and baseline JIT use,
2808         rounded up to a stack aligned number of VirtualRegisters.
2809         The LLInt explicitly saves and restores the registers in the macros
2810         preserveCalleeSavesUsedByLLInt and restoreCalleeSavesUsedByLLInt.
2811         The JITs saves and restores callee saves registers by what registers
2812         are included in m_calleeSaveRegisters in the code block.
2813
2814         Added handling of callee save register restoration to exception handling.
2815         The basic flow is when an exception is thrown or one is recognized to
2816         have been generated in C++ code, we save the current state of all
2817         callee save registers to VM::calleeSaveRegistersBuffer.  As we unwind
2818         looking for the corresponding catch, we copy the callee saves from call 
2819         frames to the same VM::calleeSaveRegistersBuffer.  This is done for all
2820         call frames on the stack up to but not including the call frame that has
2821         the corresponding catch block.  When we process the catch, we restore
2822         the callee save registers with the contents of VM::calleeSaveRegistersBuffer.
2823         If there isn't a catch, then handleUncaughtException will restore callee
2824         saves before it returns back to the calling C++.
2825
2826         Eliminated callee saves registers as free registers for various thunk
2827         generators as the callee saves may not have been saved by the function
2828         calling the thunk.
2829
2830         Added code to transition callee saves from one VM's format to the another
2831         as part of OSR entry and OSR exit.
2832
2833         Cleaned up the static RegisterSet's including adding one for LLInt and 
2834         baseline JIT callee saves and one to be used to allocate local registers
2835         not including the callee saves or other special registers.
2836
2837         Moved ftl/FTLRegisterAtOffset.{cpp,h} to jit/RegisterAtOffset.{cpp,h}.
2838         Factored out the vector of RegisterAtOffsets in ftl/FTLUnwindInfo.{cpp,h}
2839         into a new class in jit/RegisterAtOffsetList.{cpp,h}.
2840         Eliminted UnwindInfo and changed UnwindInfo::parse() into a standalone
2841         function named parseUnwindInfo.  That standalone function now returns
2842         the callee saves RegisterAtOffsetList.  This is stored in the CodeBlock
2843         and used instead of UnwindInfo.
2844
2845         Turned off register preservation thunks for outgoing calls from FTL
2846         generated code.  THey'll be removed in a subsequent patch.
2847
2848         Changed specialized thinks to save and restore the contents of
2849         tagTypeNumberRegister and tagMaskRegister as they can be called by FTL
2850         compiled functions.  We materialize those tag registers for the thunk's
2851         use and then restore the prior contents on function exit.
2852
2853         Also removed the arity check fail return thunk since it is now the
2854         caller's responsibility to restore the stack pointer.
2855
2856         Removed saving of callee save registers and materialization of special
2857         tag registers for 64 bit platforms from vmEntryToJavaScript and
2858         vmEntryToNative.
2859
2860         * CMakeLists.txt:
2861         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2862         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2863         * JavaScriptCore.xcodeproj/project.pbxproj:
2864         * ftl/FTLJITCode.h:
2865         * ftl/FTLRegisterAtOffset.cpp: Removed.
2866         * ftl/FTLRegisterAtOffset.h: Removed.
2867         * ftl/FTLUnwindInfo.cpp:
2868         (JSC::FTL::parseUnwindInfo):
2869         (JSC::FTL::UnwindInfo::UnwindInfo): Deleted.
2870         (JSC::FTL::UnwindInfo::~UnwindInfo): Deleted.
2871         (JSC::FTL::UnwindInfo::parse): Deleted.
2872         (JSC::FTL::UnwindInfo::dump): Deleted.
2873         (JSC::FTL::UnwindInfo::find): Deleted.
2874         (JSC::FTL::UnwindInfo::indexOf): Deleted.
2875         * ftl/FTLUnwindInfo.h:
2876         (JSC::RegisterAtOffset::dump):
2877         * jit/RegisterAtOffset.cpp: Added.
2878         * jit/RegisterAtOffset.h: Added.
2879         (JSC::RegisterAtOffset::RegisterAtOffset):
2880         (JSC::RegisterAtOffset::operator!):
2881         (JSC::RegisterAtOffset::reg):
2882         (JSC::RegisterAtOffset::offset):
2883         (JSC::RegisterAtOffset::offsetAsIndex):
2884         (JSC::RegisterAtOffset::operator==):
2885         (JSC::RegisterAtOffset::operator<):
2886         (JSC::RegisterAtOffset::getReg):
2887         * jit/RegisterAtOffsetList.cpp: Added.
2888         (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
2889         (JSC::RegisterAtOffsetList::sort):
2890         (JSC::RegisterAtOffsetList::dump):
2891         (JSC::RegisterAtOffsetList::find):
2892         (JSC::RegisterAtOffsetList::indexOf):
2893         * jit/RegisterAtOffsetList.h: Added.
2894         (JSC::RegisterAtOffsetList::clear):
2895         (JSC::RegisterAtOffsetList::size):
2896         (JSC::RegisterAtOffsetList::at):
2897         (JSC::RegisterAtOffsetList::append):
2898         Move and refactored use of FTLRegisterAtOffset to RegisterAtOffset.
2899         Added RegisterAtOffset and RegisterAtOffsetList to build configurations.
2900         Remove FTLRegisterAtOffset files.
2901
2902         * bytecode/CallLinkInfo.h:
2903         (JSC::CallLinkInfo::setUpCallFromFTL):
2904         Turned off FTL register preservation thunks.
2905
2906         * bytecode/CodeBlock.cpp:
2907         (JSC::CodeBlock::CodeBlock):
2908         (JSC::CodeBlock::setCalleeSaveRegisters):
2909         (JSC::roundCalleeSaveSpaceAsVirtualRegisters):
2910         (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
2911         (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
2912         * bytecode/CodeBlock.h:
2913         (JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
2914         (JSC::CodeBlock::calleeSaveRegisters):
2915         (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
2916         (JSC::CodeBlock::optimizeAfterWarmUp):
2917         (JSC::CodeBlock::numberOfDFGCompiles):
2918         Methods to manage a set of callee save registers.  Also to allocate the appropriate
2919         number of VirtualRegisters for callee saves.
2920
2921         * bytecompiler/BytecodeGenerator.cpp:
2922         (JSC::BytecodeGenerator::BytecodeGenerator):
2923         (JSC::BytecodeGenerator::allocateCalleeSaveSpace):
2924         * bytecompiler/BytecodeGenerator.h:
2925         Allocate the appropriate number of VirtualRegisters for callee saves needed by LLInt or baseline JIT.
2926
2927         * dfg/DFGJITCompiler.cpp:
2928         (JSC::DFG::JITCompiler::compileEntry):
2929         (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
2930         (JSC::DFG::JITCompiler::compileBody):
2931         (JSC::DFG::JITCompiler::compileExceptionHandlers):
2932         (JSC::DFG::JITCompiler::compile):
2933         (JSC::DFG::JITCompiler::compileFunction):
2934         * dfg/DFGJITCompiler.h:
2935         * interpreter/Interpreter.cpp:
2936         (JSC::UnwindFunctor::operator()):
2937         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
2938         * dfg/DFGPlan.cpp:
2939         (JSC::DFG::Plan::compileInThreadImpl):
2940         * dfg/DFGSpeculativeJIT.cpp:
2941         (JSC::DFG::SpeculativeJIT::usedRegisters):
2942         * dfg/DFGSpeculativeJIT32_64.cpp:
2943         (JSC::DFG::SpeculativeJIT::compile):
2944         * dfg/DFGSpeculativeJIT64.cpp:
2945         (JSC::DFG::SpeculativeJIT::compile):
2946         * dfg/DFGStackLayoutPhase.cpp:
2947         (JSC::DFG::StackLayoutPhase::run):
2948         * ftl/FTLCompile.cpp:
2949         (JSC::FTL::fixFunctionBasedOnStackMaps):
2950         (JSC::FTL::compile):
2951         * ftl/FTLLink.cpp:
2952         (JSC::FTL::link):
2953         * ftl/FTLOSRExitCompiler.cpp:
2954         (JSC::FTL::compileStub):
2955         * ftl/FTLThunks.cpp:
2956         (JSC::FTL::osrExitGenerationThunkGenerator):
2957         * jit/ArityCheckFailReturnThunks.cpp: Removed.
2958         * jit/ArityCheckFailReturnThunks.h: Removed.
2959         * jit/JIT.cpp:
2960         (JSC::JIT::emitEnterOptimizationCheck):
2961         (JSC::JIT::privateCompile):
2962         (JSC::JIT::privateCompileExceptionHandlers):
2963         * jit/JITCall32_64.cpp:
2964         (JSC::JIT::emit_op_ret):
2965         * jit/JITExceptions.cpp:
2966         (JSC::genericUnwind):
2967         * jit/JITExceptions.h:
2968         * jit/JITOpcodes.cpp:
2969         (JSC::JIT::emit_op_end):
2970         (JSC::JIT::emit_op_ret):
2971         (JSC::JIT::emit_op_throw):
2972         (JSC::JIT::emit_op_catch):
2973         (JSC::JIT::emit_op_enter):
2974         (JSC::JIT::emitSlow_op_loop_hint):
2975         * jit/JITOpcodes32_64.cpp:
2976         (JSC::JIT::emit_op_end):
2977         (JSC::JIT::emit_op_throw):
2978         (JSC::JIT::emit_op_catch):
2979         * jit/JITOperations.cpp:
2980         * jit/Repatch.cpp:
2981         (JSC::generateByIdStub):
2982         * jit/ThunkGenerators.cpp:
2983         * llint/LLIntData.cpp:
2984         (JSC::LLInt::Data::performAssertions):
2985         * llint/LLIntSlowPaths.cpp:
2986         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2987         * llint/LowLevelInterpreter.asm:
2988         * llint/LowLevelInterpreter32_64.asm:
2989         * llint/LowLevelInterpreter64.asm:
2990         (JSC::throwExceptionFromCallSlowPathGenerator):
2991         (JSC::arityFixupGenerator):
2992         * runtime/CommonSlowPaths.cpp:
2993         (JSC::setupArityCheckData):
2994         * runtime/CommonSlowPaths.h:
2995         (JSC::CommonSlowPaths::arityCheckFor):
2996         Emit code to save and restore callee save registers and materialize tagTypeNumberRegister
2997         and tagMaskRegister.
2998         Handle callee saves when tiering up.
2999         Copy callee saves register contents to VM::calleeSaveRegistersBuffer at beginning of
3000         exception processing.
3001         Process callee save registers in frames when unwinding from an exception.
3002         Restore callee saves register contents from VM::calleeSaveRegistersBuffer on catch.
3003         Use appropriate register set to make sure we don't allocate a callee save register when
3004         compiling a thunk.
3005         Helper to populate tagTypeNumberRegister and tagMaskRegister with the appropriate
3006         constants.
3007         Removed arity fixup return thunks.
3008
3009         * dfg/DFGOSREntry.cpp:
3010         (JSC::DFG::prepareOSREntry):
3011         * dfg/DFGOSRExitCompiler32_64.cpp:
3012         (JSC::DFG::OSRExitCompiler::compileExit):
3013         * dfg/DFGOSRExitCompiler64.cpp:
3014         (JSC::DFG::OSRExitCompiler::compileExit):
3015         * dfg/DFGOSRExitCompilerCommon.cpp:
3016         (JSC::DFG::reifyInlinedCallFrames):
3017         (JSC::DFG::adjustAndJumpToTarget):
3018         Restore callee saves from the DFG and save the appropriate ones for the baseline JIT.
3019         Materialize the tag registers on 64 bit platforms.
3020
3021         * jit/AssemblyHelpers.h:
3022         (JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
3023         (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
3024         (JSC::AssemblyHelpers::emitSaveCalleeSaves):
3025         (JSC::AssemblyHelpers::emitRestoreCalleeSaves):
3026         (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
3027         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer):
3028         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer):
3029         (JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
3030         New helpers to save and restore callee saves as well as materialize the tag registers
3031         contents.
3032
3033         * jit/FPRInfo.h:
3034         * jit/GPRInfo.h:
3035         (JSC::GPRInfo::toRegister):
3036         Updated to include FP callee save registers.  Added number of callee saves registers and
3037         cleanup register aliases that collide with callee save registers.
3038
3039         * jit/JITPropertyAccess.cpp:
3040         (JSC::JIT::emitGetByValWithCachedId):
3041         (JSC::JIT::emitPutByValWithCachedId):
3042         (JSC::JIT::emit_op_get_by_id):
3043         (JSC::JIT::emit_op_put_by_id):
3044         * jit/JITPropertyAccess32_64.cpp:
3045         (JSC::JIT::emitGetByValWithCachedId):
3046         (JSC::JIT::emitPutByValWithCachedId):
3047         (JSC::JIT::emit_op_get_by_id):
3048         (JSC::JIT::emit_op_put_by_id):
3049         Uses new stubUnavailableRegisters register set to limit what registers are available for 
3050         temporaries.
3051
3052         * jit/RegisterSet.cpp:
3053         (JSC::RegisterSet::stubUnavailableRegisters):
3054         (JSC::RegisterSet::calleeSaveRegisters):
3055         (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
3056         (JSC::RegisterSet::dfgCalleeSaveRegisters):
3057         (JSC::RegisterSet::ftlCalleeSaveRegisters):
3058         * jit/RegisterSet.h:
3059         New register sets with the callee saves used by various tiers as well as one listing registers
3060         not availble to stub code.
3061
3062         * jit/SpecializedThunkJIT.h:
3063         (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
3064         (JSC::SpecializedThunkJIT::loadDoubleArgument):
3065         (JSC::SpecializedThunkJIT::returnJSValue):
3066         (JSC::SpecializedThunkJIT::returnDouble):
3067         (JSC::SpecializedThunkJIT::returnInt32):
3068         (JSC::SpecializedThunkJIT::returnJSCell):
3069         (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
3070         (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters):
3071         (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters):
3072         (JSC::SpecializedThunkJIT::tagReturnAsInt32):
3073         * jit/ThunkGenerators.cpp:
3074         (JSC::nativeForGenerator):
3075         Changed to save and restore existing tag register contents as the may contain other values.
3076         After saving the existing values, we materialize the tag constants.
3077
3078         * jit/TempRegisterSet.h:
3079         (JSC::TempRegisterSet::getFPRByIndex):
3080         (JSC::TempRegisterSet::getFreeFPR):
3081         (JSC::TempRegisterSet::setByIndex):
3082         * offlineasm/arm64.rb:
3083         * offlineasm/registers.rb:
3084         Added methods for floating point registers to support callee save FP registers.
3085
3086         * jit/JITArithmetic32_64.cpp:
3087         (JSC::JIT::emit_op_mod):
3088         Removed unnecessary #if CPU(X86_64) check to this 32 bit only file.
3089
3090         * offlineasm/x86.rb:
3091         Fixed Windows callee saves naming.
3092
3093         * runtime/VM.cpp:
3094         (JSC::VM::VM):
3095         * runtime/VM.h:
3096         (JSC::VM::calleeSaveRegistersBufferOffset):
3097         (JSC::VM::getAllCalleeSaveRegistersMap):
3098         Provide a RegisterSaveMap that has all registers that might be saved.  Added a callee save buffer to be
3099         used for OSR exit and for exception processing in a future patch.
3100
3101 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
3102
3103         ModuleProgramExecutable should provide CodeBlock to ScriptExecutable::forEachCodeBlock
3104         https://bugs.webkit.org/show_bug.cgi?id=149028
3105
3106         Reviewed by Michael Saboff.
3107
3108         ModuleProgramExecutable should provide CodeBlock since ModuleProgramExecutable inherits
3109         ScriptExecutable.
3110
3111         * bytecode/CodeBlock.h:
3112         (JSC::ScriptExecutable::forEachCodeBlock):
3113
3114 2015-09-09  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3115
3116         Implement internal calls in WebAssembly
3117         https://bugs.webkit.org/show_bug.cgi?id=148998
3118
3119         Reviewed by Filip Pizlo.
3120
3121         This patch implements internal calls to functions that return a 32-bit
3122         integer in WebAssembly.
3123
3124         * tests/stress/wasm-calls.js: Added.
3125         (shouldBe):
3126         * tests/stress/wasm/calls.wasm: Added.
3127         * wasm/WASMFunctionCompiler.h:
3128         (JSC::WASMFunctionCompiler::WASMFunctionCompiler):
3129         (JSC::WASMFunctionCompiler::endFunction):
3130         (JSC::WASMFunctionCompiler::buildCallInternal):
3131         (JSC::WASMFunctionCompiler::appendExpressionList):
3132         (JSC::WASMFunctionCompiler::emitNakedCall):
3133         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
3134         (JSC::WASMFunctionCompiler::callAndUnboxResult):
3135         * wasm/WASMFunctionParser.cpp:
3136         (JSC::WASMFunctionParser::compile):
3137         (JSC::WASMFunctionParser::parseExpressionI32):
3138         (JSC::WASMFunctionParser::parseCallInternalExpressionI32):
3139         (JSC::WASMFunctionParser::parseCallArguments):
3140         (JSC::WASMFunctionParser::parseCallInternal):
3141         * wasm/WASMFunctionParser.h:
3142         * wasm/WASMFunctionSyntaxChecker.h:
3143         (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
3144         (JSC::WASMFunctionSyntaxChecker::appendExpressionList):
3145
3146 2015-09-09  Commit Queue  <commit-queue@webkit.org>
3147
3148         Unreviewed, rolling out r189522.
3149         https://bugs.webkit.org/show_bug.cgi?id=149020
3150
3151         "Caused a ~4% Speedometer regression" (Requested by cdumez on
3152         #webkit).
3153
3154         Reverted changeset:
3155
3156         "Function.prototype.bind: Bound functions must use the
3157         [[Prototype]] of their target function instead of
3158         Function.prototype"
3159         https://bugs.webkit.org/show_bug.cgi?id=145605
3160         http://trac.webkit.org/changeset/189522
3161
3162 2015-09-09  Geoffrey Garen  <ggaren@apple.com>
3163
3164         Fix the no-DFG build.
3165
3166         Unreviewed.
3167
3168         * bytecode/CodeBlock.cpp:
3169         (JSC::CodeBlock::visitOSRExitTargets):
3170         (JSC::CodeBlock::stronglyVisitStrongReferences):
3171
3172 2015-09-09  Geoffrey Garen  <ggaren@apple.com>
3173
3174         CodeBlocks should strongly visit their OSR exit targets
3175         https://bugs.webkit.org/show_bug.cgi?id=148988
3176
3177         Reviewed by Saam Barati.
3178
3179         CodeBlocks jump to their OSR exit targets, so we need to keep them alive
3180         explicitly.
3181
3182         This is a step toward throwing away CodeBlocks, which is only safe
3183         if we keep alive logically in-use CodeBlocks.
3184
3185         * bytecode/CodeBlock.cpp:
3186         (JSC::CodeBlock::CodeBlock):
3187         (JSC::CodeBlock::visitStrongly): Added a flag to indicate if visit
3188         strongly had been performed yet, since we are likely to revisit
3189         the same CodeBlock many times now.
3190
3191         (JSC::CodeBlock::visitOSRExitTargets):
3192         (JSC::CodeBlock::stronglyVisitStrongReferences): Do the visiting.
3193
3194         * bytecode/CodeBlock.h:
3195         (JSC::CodeBlock::clearMarks):
3196         (JSC::CodeBlockSet::mark): Added a helper function for clearing out
3197         two flags.
3198
3199 2015-09-09  Geoffrey Garen  <ggaren@apple.com>
3200
3201         Unreviewed, rolling back in r189516.
3202         https://bugs.webkit.org/show_bug.cgi?id=148989
3203
3204         Restored changeset:
3205
3206         "GC should be able to discover new strong CodeBlock references
3207         during marking"
3208         https://bugs.webkit.org/show_bug.cgi?id=148981
3209         http://trac.webkit.org/changeset/189516
3210
3211         This patch caused infinite recursion on Windows because of a pre-existing
3212         logical error in the non-parallel GC configuration. Even in non-parallel
3213         GC, we must set the mark bit on a CodeBlock to avoid marking it twice
3214         (or, in the case of our crash, infinitely recursively).
3215
3216 2015-09-09  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3217
3218         Implement the relational instructions for doubles in WebAssembly
3219         https://bugs.webkit.org/show_bug.cgi?id=148999
3220
3221         Reviewed by Filip Pizlo.
3222
3223         Implements the relational instructions for doubles (float64) in
3224         WebAssembly. Also pass the values into the test functions as Mark Lam
3225         suggested in https://bugs.webkit.org/show_bug.cgi?id=148882#c3
3226
3227         * tests/stress/wasm-relational.js:
3228         * tests/stress/wasm/relational.wasm:
3229         * wasm/WASMFunctionCompiler.h:
3230         (JSC::WASMFunctionCompiler::buildRelationalF64):
3231         * wasm/WASMFunctionParser.cpp:
3232         (JSC::WASMFunctionParser::parseExpressionI32):
3233         (JSC::WASMFunctionParser::parseRelationalF64ExpressionI32):
3234         * wasm/WASMFunctionParser.h:
3235         * wasm/WASMFunctionSyntaxChecker.h:
3236         (JSC::WASMFunctionSyntaxChecker::buildRelationalI32):
3237         (JSC::WASMFunctionSyntaxChecker::buildRelationalF64):
3238
3239 2015-09-09  Saam barati  <sbarati@apple.com>
3240
3241         DFG should have a debugging option that runs a phase that flushes all locals
3242         https://bugs.webkit.org/show_bug.cgi?id=148916
3243
3244         Reviewed by Filip Pizlo.
3245
3246         There is now an option to enable the DFG's new MaximalFlushInsertionPhase
3247         phase to run. This phase ensures that we keep all locals and arguments flushed
3248         to the stack at all places in the CFG. This phase is helpful for finding
3249         a class of bugs where enabling this phase to run removes the bug.
3250         This may also be useful in the development of a faster debugger
3251         that doesn't capture all variables.
3252
3253         * CMakeLists.txt:
3254         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3255         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3256         * JavaScriptCore.xcodeproj/project.pbxproj:
3257         * dfg/DFGMaximalFlushInsertionPhase.cpp: Added.
3258         (JSC::DFG::MaximalFlushInsertionPhase::MaximalFlushInsertionPhase):
3259         (JSC::DFG::MaximalFlushInsertionPhase::run):
3260         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
3261         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
3262         (JSC::DFG::MaximalFlushInsertionPhase::newVariableAccessData):
3263         (JSC::DFG::performMaximalFlushInsertion):
3264         * dfg/DFGMaximalFlushInsertionPhase.h: Added.
3265         * dfg/DFGPlan.cpp:
3266         (JSC::DFG::Plan::compileInThreadImpl):
3267         * runtime/Options.cpp:
3268         (JSC::recomputeDependentOptions):
3269         * runtime/Options.h:
3270
3271 2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3272
3273         Refactor the test for the arithmetic instructions in WebAssembly
3274         https://bugs.webkit.org/show_bug.cgi?id=148983
3275
3276         Reviewed by Mark Lam.
3277
3278         Pass the values into the test functions as Mark Lam suggested in
3279         https://bugs.webkit.org/show_bug.cgi?id=148882#c3
3280
3281         * tests/stress/wasm-arithmetic-int32.js: Added.
3282         (shouldBe):
3283         (shouldThrow):
3284         * tests/stress/wasm-arithmetic.js: Removed.
3285         (shouldBe): Deleted.
3286         (shouldThrow): Deleted.
3287         * tests/stress/wasm/arithmetic-int32.wasm: Added.
3288         * tests/stress/wasm/arithmetic.wasm: Removed.
3289
3290 2015-09-08  Benjamin Poulain  <bpoulain@apple.com>
3291
3292         [JSC] reduce the amount of memory access needed for LivenessAnalysisPhase
3293         https://bugs.webkit.org/show_bug.cgi?id=148414
3294
3295         Reviewed by Mark Lam.
3296
3297         LivenessAnalysisPhase still causes a huge number of cache miss.
3298         This patch reduces the amount of accesses needed by the HashTables.
3299
3300         * dfg/DFGBasicBlock.h:
3301         * dfg/DFGLivenessAnalysisPhase.cpp:
3302         (JSC::DFG::LivenessAnalysisPhase::run):
3303         (JSC::DFG::LivenessAnalysisPhase::process):
3304
3305 2015-09-08  Myles C. Maxfield  <mmaxfield@apple.com>
3306
3307         Prospective build fix after r189517
3308
3309         Unreviewed.
3310
3311         * heap/MachineStackMarker.cpp:
3312         (JSC::MachineThreads::Thread::captureStack):
3313
3314 2015-09-08  Yusuke Suzuki  <utatane.tea@gmail.com>
3315
3316         Unify symbolTableGet and Put in JSLexicalEnvironment and JSSymbolTableObject
3317         https://bugs.webkit.org/show_bug.cgi?id=148783
3318
3319         Reviewed by Geoffrey Garen.
3320
3321         Unify the symbolTableGet and symbolTablePut into JSSymbolTableObject's one.
3322         Since symbolTablePutWithAttributes in JSLexicalEnvironment is not used, we drop that function.
3323
3324         * runtime/JSEnvironmentRecord.h:
3325         (JSC::JSEnvironmentRecord::isValidScopeOffset):
3326         (JSC::JSEnvironmentRecord::variableAt):
3327         (JSC::JSEnvironmentRecord::isValid): Deleted.
3328         * runtime/JSGlobalLexicalEnvironment.cpp:
3329         (JSC::JSGlobalLexicalEnvironment::put):
3330         * runtime/JSGlobalObject.cpp:
3331         (JSC::JSGlobalObject::put):
3332         * runtime/JSLexicalEnvironment.cpp:
3333         (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
3334         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
3335         (JSC::JSLexicalEnvironment::put):