a3fdab7da90f0282c605c66c823b55c954ff86c9
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-09-24  Mark Lam  <mark.lam@apple.com>
2
3         Remove the use of "Immediate" in JIT function names.
4         https://bugs.webkit.org/show_bug.cgi?id=149542
5
6         Reviewed by Geoffrey Garen.
7
8         We will rename the following:
9             isOperandConstantImmediateDouble => isOperandConstantDouble
10             isOperandConstantImmediateInt => isOperandConstantInt
11             isOperandConstantImmediateChar => isOperandConstantChar
12
13             getOperandConstantImmediateInt => getOperandConstantInt
14             getConstantOperandImmediateInt => getOperandConstantInt
15
16             emitJumpIfImmediateInteger => emitJumpIfInt
17             emitJumpIfNotImmediateInteger => emitJumpIfNotInt
18             emitJumpIfNotImmediateIntegers => emitJumpIfNotInt
19             emitPatchableJumpIfNotImmediateInteger => emitPatchableJumpIfNotInt
20             emitJumpSlowCaseIfNotImmediateInteger => emitJumpSlowCaseIfNotInt
21             emitJumpSlowCaseIfNotImmediateNumber => emitJumpSlowCaseIfNotNumber
22             emitJumpSlowCaseIfNotImmediateIntegers => emitJumpSlowCaseIfNotInt
23             emitFastArithReTagImmediate => emitTagInt
24             emitTagAsBoolImmediate => emitTagBool
25             emitJumpIfImmediateNumber => emitJumpIfNumber
26             emitJumpIfNotImmediateNumber => emitJumpIfNotNumber
27             emitFastArithImmToInt - Deleted because this is an empty function.
28             emitFastArithIntToImmNoCheck => emitTagInt
29             emitPutImmediateToCallFrameHeader => emitPutToCallFrameHeader
30
31         This is purely a refactoring patch to do the renaming.  There is no behavior
32         change.
33
34         * dfg/DFGJITCompiler.cpp:
35         (JSC::DFG::JITCompiler::compileEntry):
36         (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
37         * jit/AssemblyHelpers.h:
38         (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
39         (JSC::AssemblyHelpers::emitPutImmediateToCallFrameHeader): Deleted.
40         * jit/JIT.cpp:
41         (JSC::JIT::privateCompile):
42         * jit/JIT.h:
43         (JSC::JIT::emitStoreCell):
44         (JSC::JIT::getSlowCase):
45         * jit/JITArithmetic.cpp:
46         (JSC::JIT::emit_op_negate):
47         (JSC::JIT::emit_op_lshift):
48         (JSC::JIT::emit_op_rshift):
49         (JSC::JIT::emitSlow_op_rshift):
50         (JSC::JIT::emit_op_urshift):
51         (JSC::JIT::emitSlow_op_urshift):
52         (JSC::JIT::emit_op_unsigned):
53         (JSC::JIT::emit_compareAndJump):
54         (JSC::JIT::emit_compareAndJumpSlow):
55         (JSC::JIT::emit_op_bitand):
56         (JSC::JIT::emit_op_inc):
57         (JSC::JIT::emit_op_dec):
58         (JSC::JIT::emit_op_mod):
59         (JSC::JIT::compileBinaryArithOp):
60         (JSC::JIT::compileBinaryArithOpSlowCase):
61         (JSC::JIT::emit_op_add):
62         (JSC::JIT::emitSlow_op_add):
63         (JSC::JIT::emit_op_mul):
64         (JSC::JIT::emitSlow_op_mul):
65         (JSC::JIT::emit_op_div):
66         (JSC::JIT::emitSlow_op_div):
67         * jit/JITArithmetic32_64.cpp:
68         (JSC::JIT::emit_compareAndJump):
69         (JSC::JIT::emit_compareAndJumpSlow):
70         (JSC::JIT::emit_op_lshift):
71         (JSC::JIT::emitSlow_op_lshift):
72         (JSC::JIT::emitRightShift):
73         (JSC::JIT::emitRightShiftSlowCase):
74         (JSC::JIT::emit_op_bitand):
75         (JSC::JIT::emitSlow_op_bitand):
76         (JSC::JIT::emit_op_bitor):
77         (JSC::JIT::emitSlow_op_bitor):
78         (JSC::JIT::emit_op_bitxor):
79         (JSC::JIT::emitSlow_op_bitxor):
80         (JSC::JIT::emit_op_add):
81         (JSC::JIT::emitSlow_op_add):
82         (JSC::JIT::emit_op_sub):
83         (JSC::JIT::emitSlow_op_sub):
84         * jit/JITInlines.h:
85         (JSC::JIT::emitArrayStorageGetByVal):
86         (JSC::JIT::isOperandConstantDouble):
87         (JSC::JIT::isOperandConstantChar):
88         (JSC::JIT::emitJumpSlowCaseIfNotJSCell):
89         (JSC::JIT::isOperandConstantInt):
90         (JSC::JIT::getOperandConstantInt):
91         (JSC::JIT::emitGetVirtualRegisters):
92         (JSC::JIT::emitLoadInt32ToDouble):
93         (JSC::JIT::emitJumpIfInt):
94         (JSC::JIT::emitJumpIfNotInt):
95         (JSC::JIT::emitPatchableJumpIfNotInt):
96         (JSC::JIT::emitJumpSlowCaseIfNotInt):
97         (JSC::JIT::emitJumpSlowCaseIfNotNumber):
98         (JSC::JIT::emitTagBool):
99         (JSC::JIT::isOperandConstantImmediateDouble): Deleted.
100         (JSC::JIT::isOperandConstantImmediateChar): Deleted.
101         (JSC::JIT::isOperandConstantImmediateInt): Deleted.
102         (JSC::JIT::getOperandConstantImmediateInt): Deleted.
103         (JSC::JIT::getConstantOperandImmediateInt): Deleted.
104         (JSC::JIT::emitJumpIfImmediateInteger): Deleted.
105         (JSC::JIT::emitJumpIfNotImmediateInteger): Deleted.
106         (JSC::JIT::emitPatchableJumpIfNotImmediateInteger): Deleted.
107         (JSC::JIT::emitJumpIfNotImmediateIntegers): Deleted.
108         (JSC::JIT::emitJumpSlowCaseIfNotImmediateInteger): Deleted.
109         (JSC::JIT::emitJumpSlowCaseIfNotImmediateIntegers): Deleted.
110         (JSC::JIT::emitJumpSlowCaseIfNotImmediateNumber): Deleted.
111         (JSC::JIT::emitFastArithReTagImmediate): Deleted.
112         (JSC::JIT::emitTagAsBoolImmediate): Deleted.
113         * jit/JITOpcodes.cpp:
114         (JSC::JIT::emit_op_is_undefined):
115         (JSC::JIT::emit_op_is_boolean):
116         (JSC::JIT::emit_op_is_number):
117         (JSC::JIT::emit_op_is_string):
118         (JSC::JIT::emit_op_is_object):
119         (JSC::JIT::emit_op_jfalse):
120         (JSC::JIT::emit_op_eq):
121         (JSC::JIT::emit_op_jtrue):
122         (JSC::JIT::emit_op_neq):
123         (JSC::JIT::emit_op_bitxor):
124         (JSC::JIT::emit_op_bitor):
125         (JSC::JIT::compileOpStrictEq):
126         (JSC::JIT::emit_op_to_number):
127         (JSC::JIT::emit_op_eq_null):
128         (JSC::JIT::emit_op_neq_null):
129         (JSC::JIT::emitSlow_op_eq):
130         (JSC::JIT::emitSlow_op_neq):
131         (JSC::JIT::emit_op_profile_type):
132         * jit/JITOpcodes32_64.cpp:
133         (JSC::JIT::privateCompileCTINativeCall):
134         * jit/JITPropertyAccess.cpp:
135         (JSC::JIT::emit_op_get_by_val):
136         (JSC::JIT::emit_op_put_by_val):
137         (JSC::JIT::emitGenericContiguousPutByVal):
138         (JSC::JIT::emit_op_put_by_id):
139         (JSC::JIT::emitIntTypedArrayPutByVal):
140         (JSC::JIT::emitFloatTypedArrayPutByVal):
141         * jit/JSInterfaceJIT.h:
142         (JSC::JSInterfaceJIT::emitJumpIfNotJSCell):
143         (JSC::JSInterfaceJIT::emitJumpIfNumber):
144         (JSC::JSInterfaceJIT::emitJumpIfNotNumber):
145         (JSC::JSInterfaceJIT::emitLoadDouble):
146         (JSC::JSInterfaceJIT::emitTagInt):
147         (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
148         (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber): Deleted.
149         (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber): Deleted.
150         (JSC::JSInterfaceJIT::emitFastArithImmToInt): Deleted.
151         (JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck): Deleted.
152         (JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader): Deleted.
153         * jit/ThunkGenerators.cpp:
154         (JSC::nativeForGenerator):
155         * wasm/WASMFunctionCompiler.h:
156         (JSC::WASMFunctionCompiler::startFunction):
157         (JSC::WASMFunctionCompiler::endFunction):
158
159 2015-09-24  Michael Saboff  <msaboff@apple.com>
160
161         [ES6] Implement tail calls in the DFG
162         https://bugs.webkit.org/show_bug.cgi?id=148663
163
164         Reviewed by Filip Pizlo.
165
166         jsc-tailcall: Implement the tail call opcodes in the DFG
167         https://bugs.webkit.org/show_bug.cgi?id=146850
168
169         This patch adds support for tail calls in the DFG. This requires a slightly high number of nodes:
170
171          - TailCall and TailCallVarargs are straightforward. They are terminal
172            nodes and have the semantics of an actual tail call.
173
174          - TailCallInlinedCaller and TailCallVarargsInlinedCaller are here to perform a
175            tail call inside an inlined function. They are non terminal nodes,
176            and are performing the call as a regular call after popping an
177            appropriate number of inlined tail call frames.
178
179          - TailCallForwardVarargs and TailCallForwardVarargsInlinedCaller are the
180            extension of TailCallVarargs and TailCallVarargsInlinedCaller to enable
181            the varargs forwarding optimization so that we don't lose
182            performance with a tail call instead of a regular call.
183
184         This also required two broad kind of changes:
185
186          - Changes in the JIT itself (DFGSpeculativeJIT) are pretty
187            straightforward since they are just an extension of the baseline JIT
188            changes introduced previously.
189
190          - Changes in the runtime are mostly related with handling inline call
191            frames. The idea here is that we have a special TailCall type for
192            call frames that indicates to the various pieces of code walking the
193            inline call frame that they should (recursively) skip the caller in
194            their analysis.
195
196         * bytecode/CallMode.h:
197         (JSC::specializationKindFor):
198         * bytecode/CodeOrigin.cpp:
199         (JSC::CodeOrigin::inlineDepthForCallFrame):
200         (JSC::CodeOrigin::isApproximatelyEqualTo):
201         (JSC::CodeOrigin::approximateHash):
202         (JSC::CodeOrigin::inlineStack):
203         * bytecode/CodeOrigin.h:
204         * bytecode/InlineCallFrame.cpp:
205         (JSC::InlineCallFrame::dumpInContext):
206         (WTF::printInternal):
207         * bytecode/InlineCallFrame.h:
208         (JSC::InlineCallFrame::callModeFor):
209         (JSC::InlineCallFrame::kindFor):
210         (JSC::InlineCallFrame::varargsKindFor):
211         (JSC::InlineCallFrame::specializationKindFor):
212         (JSC::InlineCallFrame::isVarargs):
213         (JSC::InlineCallFrame::isTail):
214         (JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
215         (JSC::InlineCallFrame::getCallerSkippingDeadFrames):
216         (JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames):
217         * dfg/DFGAbstractInterpreterInlines.h:
218         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
219         * dfg/DFGArgumentsEliminationPhase.cpp:
220         * dfg/DFGBasicBlock.h:
221         (JSC::DFG::BasicBlock::findTerminal):
222         * dfg/DFGByteCodeParser.cpp:
223         (JSC::DFG::ByteCodeParser::inlineCallFrame):
224         (JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
225         (JSC::DFG::ByteCodeParser::currentCodeOrigin):
226         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
227         (JSC::DFG::ByteCodeParser::addCall):
228         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
229         (JSC::DFG::ByteCodeParser::getPrediction):
230         (JSC::DFG::ByteCodeParser::handleCall):
231         (JSC::DFG::ByteCodeParser::handleVarargsCall):
232         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
233         (JSC::DFG::ByteCodeParser::inliningCost):
234         (JSC::DFG::ByteCodeParser::inlineCall):
235         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
236         (JSC::DFG::ByteCodeParser::parseBlock):
237         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
238         (JSC::DFG::ByteCodeParser::parseCodeBlock):
239         * dfg/DFGCapabilities.cpp:
240         (JSC::DFG::capabilityLevel):
241         * dfg/DFGClobberize.h:
242         (JSC::DFG::clobberize):
243         * dfg/DFGDoesGC.cpp:
244         (JSC::DFG::doesGC):
245         * dfg/DFGFixupPhase.cpp:
246         (JSC::DFG::FixupPhase::fixupNode):
247         * dfg/DFGGraph.cpp:
248         (JSC::DFG::Graph::isLiveInBytecode):
249         * dfg/DFGGraph.h:
250         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
251         * dfg/DFGInPlaceAbstractState.cpp:
252         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
253         * dfg/DFGJITCompiler.cpp:
254         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
255         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
256         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
257         * dfg/DFGNode.h:
258         (JSC::DFG::Node::hasCallVarargsData):
259         (JSC::DFG::Node::isTerminal):
260         (JSC::DFG::Node::hasHeapPrediction):
261         * dfg/DFGNodeType.h:
262         * dfg/DFGOSRExitCompilerCommon.cpp:
263         (JSC::DFG::handleExitCounts):
264         (JSC::DFG::reifyInlinedCallFrames):
265         (JSC::DFG::osrWriteBarrier):
266         * dfg/DFGOSRExitPreparation.cpp:
267         (JSC::DFG::prepareCodeOriginForOSRExit):
268         * dfg/DFGOperations.cpp:
269         * dfg/DFGPreciseLocalClobberize.h:
270         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
271         * dfg/DFGPredictionPropagationPhase.cpp:
272         (JSC::DFG::PredictionPropagationPhase::propagate):
273         * dfg/DFGSafeToExecute.h:
274         (JSC::DFG::safeToExecute):
275         * dfg/DFGSpeculativeJIT32_64.cpp:
276         (JSC::DFG::SpeculativeJIT::emitCall):
277         (JSC::DFG::SpeculativeJIT::compile):
278         * dfg/DFGSpeculativeJIT64.cpp:
279         (JSC::DFG::SpeculativeJIT::emitCall):
280         (JSC::DFG::SpeculativeJIT::compile):
281         * dfg/DFGValidate.cpp:
282         (JSC::DFG::Validate::validateSSA):
283         * dfg/DFGVarargsForwardingPhase.cpp:
284         * interpreter/CallFrame.cpp:
285         (JSC::CallFrame::bytecodeOffset):
286         * interpreter/StackVisitor.cpp:
287         (JSC::StackVisitor::gotoNextFrame):
288
289 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
290
291         Remove special case code for the no-parallel-GC case
292         https://bugs.webkit.org/show_bug.cgi?id=149512
293
294         Reviewed by Mark Lam.
295
296         Make serial GC just a parallel GC where the helper threads don't do anything. Also make the
297         idle thread calculation a bit more explicit.
298
299         The main outcome is that we no longer use Options::numberOfGCMarkers() as much, so the code is
300         resilient against the number of GC markers changing.
301
302         * heap/Heap.h:
303         * heap/SlotVisitor.cpp:
304         (JSC::SlotVisitor::donateKnownParallel):
305         (JSC::SlotVisitor::drain):
306         (JSC::SlotVisitor::drainFromShared):
307
308 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
309
310         PolymorphicAccess should remember that it checked an ObjectPropertyCondition with a check on some structure
311         https://bugs.webkit.org/show_bug.cgi?id=149514
312
313         Reviewed by Oliver Hunt.
314
315         When we checked an ObjectPropertyCondition using an explicit structure check, we would forget to
316         note the structure in any weak reference table and we would attempt to regenerate the condition
317         check even if the condition became invalid.
318
319         We need to account for this better and we need to prune AccessCases that have an invalid condition
320         set. This change does both.
321
322         * bytecode/PolymorphicAccess.cpp:
323         (JSC::AccessGenerationState::addWatchpoint):
324         (JSC::AccessCase::alternateBase):
325         (JSC::AccessCase::couldStillSucceed):
326         (JSC::AccessCase::canReplace):
327         (JSC::AccessCase::generate):
328         (JSC::PolymorphicAccess::regenerateWithCases):
329         (JSC::PolymorphicAccess::visitWeak):
330         (JSC::PolymorphicAccess::regenerate):
331         * bytecode/PolymorphicAccess.h:
332         (JSC::AccessCase::callLinkInfo):
333         * tests/stress/make-dictionary-repatch.js: Added. This used to crash on a release assert. If we removed the release assert, this would return bad results.
334
335 2015-09-24  Mark Lam  <mark.lam@apple.com>
336
337         We should only expect a RareCaseProfile to exist if the rare case actually exists.
338         https://bugs.webkit.org/show_bug.cgi?id=149531
339
340         Reviewed by Saam Barati.
341
342         The current code that calls rareCaseProfileForBytecodeOffset() assumes that it
343         will always return a non-null RareCaseProfile.  As a result, op_add in the
344         baseline JIT is forced to add a dummy slow case that will never be taken, only to
345         ensure that the RareCaseProfile for that bytecode is created.  This profile will
346         always produce a counter value of 0 (since that path will never be taken).
347
348         Instead, we'll make the callers of rareCaseProfileForBytecodeOffset() check if
349         the profile actually exist before dereferencing it.
350
351         * bytecode/CodeBlock.cpp:
352         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
353         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
354         (JSC::CodeBlock::capabilityLevel):
355         * bytecode/CodeBlock.h:
356         (JSC::CodeBlock::addRareCaseProfile):
357         (JSC::CodeBlock::numberOfRareCaseProfiles):
358         (JSC::CodeBlock::likelyToTakeSlowCase):
359         (JSC::CodeBlock::couldTakeSlowCase):
360         (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
361         (JSC::CodeBlock::likelyToTakeAnySlowCase):
362         (JSC::CodeBlock::rareCaseProfile): Deleted.
363         * jit/JITArithmetic.cpp:
364         (JSC::JIT::emit_op_add):
365         (JSC::JIT::emitSlow_op_add):
366         * jit/JITArithmetic32_64.cpp:
367         (JSC::JIT::emit_op_add):
368         (JSC::JIT::emitSlow_op_add):
369
370 2015-09-24  Ryosuke Niwa  <rniwa@webkit.org>
371
372         Ran sort-Xcode-project-file.
373
374         * JavaScriptCore.xcodeproj/project.pbxproj:
375
376 2015-09-24  Youenn Fablet  <youenn.fablet@crf.canon.fr>
377
378         [Streams API] Add support for JS builtins constructor
379         https://bugs.webkit.org/show_bug.cgi?id=149497
380
381         Reviewed by Darin Adler.
382
383         * runtime/JSFunction.h: exporting createBuiltinFunction.
384
385 2015-09-23  Saam barati  <sbarati@apple.com>
386
387         JSC allows invalid var declarations when the declared name is the same as a let/const variable
388         https://bugs.webkit.org/show_bug.cgi?id=147600
389
390         Reviewed by Yusuke Suzuki.
391
392         We had an ordering bug where if you first declared a "let"
393         variable then a "var" variable with the same name, you wouldn't
394         get a syntax error. But, if you did it in the reverse order,
395         you would. This patch fixes this syntax error to be order independent.
396
397         * parser/Parser.cpp:
398         (JSC::Parser<LexerType>::parseVariableDeclarationList):
399         (JSC::Parser<LexerType>::createBindingPattern):
400         (JSC::Parser<LexerType>::parseFunctionDeclaration):
401         * parser/Parser.h:
402         (JSC::Scope::declareVariable):
403
404 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
405
406         Parallel copy phase synchronization should be simplified
407         https://bugs.webkit.org/show_bug.cgi?id=149509
408
409         Reviewed by Mark Lam.
410
411         Before this change, we didn't wait for the copy phase to finish before starting to do things to
412         copied space that presumed that copying was done. Copied space would "detect" that nobody was
413         copying anymore by waiting for all loaned blocks to be returned. But that would succeed if some
414         thread had not yet started copying. So, we had weird hacks to ensure that a block was loaned
415         before any threads started. It also meant that we had two separate mechanisms for waiting for
416         copying threads to finish - one mechanism in the Heap phase logic and another in the
417         CopiedSpace::doneCopying() method.
418
419         We can get rid of a lot of the weirdness by just having a sound shutdown sequence:
420
421         1) Threads concur on when there is no more work. We already have this; once
422            Heap::getNextBlocksToCopy() returns no work in any thread, it will also return no work in
423            any other thread that asks for work.
424         2) Main thread waits for the threads to not be copying anymore.
425         3) Do whatever we need to do after copying finishes.
426
427         Currently, we do (3) before (2) and so we have weird problems. This just changes the code to do
428         (3) after (2), and so we can get rid of the synchronization in doneCopying() and we can safely
429         call startCopying() inside GCThread. This also means that we don't need to make CopyVisitor a
430         property of GCThread. Instead, GCThread just instantiates its own CopyVisitor when it needs to.
431
432         * heap/CopiedSpace.cpp:
433         (JSC::CopiedSpace::doneCopying):
434         * heap/GCThread.cpp:
435         (JSC::GCThread::GCThread):
436         (JSC::GCThread::slotVisitor):
437         (JSC::GCThread::waitForNextPhase):
438         (JSC::GCThread::gcThreadMain):
439         (JSC::GCThread::copyVisitor): Deleted.
440         * heap/GCThread.h:
441         * heap/Heap.cpp:
442         (JSC::Heap::Heap):
443         (JSC::Heap::copyBackingStores):
444         (JSC::Heap::gatherStackRoots):
445
446 2015-09-23  Joseph Pecoraro  <pecoraro@apple.com>
447
448         Remove unimplemented method Heap::showStatistics
449         https://bugs.webkit.org/show_bug.cgi?id=149507
450
451         Reviewed by Darin Adler.
452
453         * heap/Heap.h:
454
455 2015-09-23  Tim Horton  <timothy_horton@apple.com>
456
457         Hopefully fix the production build.
458
459         * JavaScriptCore.xcodeproj/project.pbxproj:
460         * PlatformWin.cmake:
461
462 2015-09-23  Youenn Fablet  <youenn.fablet@crf.canon.fr>
463
464         [Streams API] Implement ReadableStream pipeThrough
465         https://bugs.webkit.org/show_bug.cgi?id=147556
466
467         Reviewed by Darin Adler.
468
469         Updating BuiltIns infrastructure to make it reusable from WebCore.
470         Extracting macros from BuiltinNames and createBuiltinExecutable from BuiltinExecutables.
471         Updated generate-js-builtins to allow generating builtin CPP/H files in WebCore namespace.
472
473         * JavaScriptCore.xcodeproj/project.pbxproj:
474         * builtins/BuiltinExecutables.cpp:
475         (JSC::BuiltinExecutables::createDefaultConstructor):
476         (JSC::BuiltinExecutables::createBuiltinExecutable):
477         (JSC::createBuiltinExecutable):
478         (JSC::createExecutableInternal):
479         * builtins/BuiltinExecutables.h:
480         * builtins/BuiltinNames.h:
481         (JSC::BuiltinNames::BuiltinNames): Deleted.
482         * builtins/BuiltinUtils.h: Extracting code from BuiltinNames and BuiltinExecutables.h.
483         * bytecode/UnlinkedFunctionExecutable.h:
484         * generate-js-builtins:
485         (getFunctions):
486         (writeIncludeDirectives):
487
488 2015-09-22  Mark Lam  <mark.lam@apple.com>
489
490         Gardening: speculative non-JIT build fix after r189999.
491
492         Not reviewed.
493
494         * bytecode/ValueRecovery.h:
495         (JSC::ValueRecovery::jsValueRegs):
496
497 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
498
499         GCThreadSharedData is just a bad way of saying Heap
500         https://bugs.webkit.org/show_bug.cgi?id=149435
501
502         Reviewed by Mark Lam.
503
504         This removes the GCThreadSharedData class and moves its members into Heap. This is a net
505         simplification since GCThreadSharedData had a 1-to-1 mapping to Heap and the two classes had a
506         vast contract with a lot of interdependencies. Heap would call a lot of GCThreadSharedData
507         methods; now a lot of those are inlined since they were only called from the one place in Heap.
508         This makes it a lot easier to see what is going on. For example, you no longer have to look at
509         code in two places (Heap and GCThreadSharedData) to figure out the timing and synchronization
510         of GC phases - all of that code is in Heap now.
511
512         This also removes weird indirections in other places. It used to be that a lot of GC helper
513         classes woud have a pointer to GCThreadSharedData, and then would use that to get to Heap, VM,
514         and the visitors. Now these helpers just point to Heap.
515
516         I think that GCThreadSharedData was only useful for defining the set of things that we need to
517         know to collect garbage. That's how we decided if something would go into GCThreadSharedData
518         instead of Heap. But I think that separating things into multiple classes usually makes the
519         code less hackable, so there should be a very high bar for doing this in a way that produces a
520         1-to-1 mapping between two classes - where one instance of one of the classes is always paired
521         with exactly one instance of the other class and vice-versa.
522
523         * CMakeLists.txt:
524         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
525         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
526         * JavaScriptCore.xcodeproj/project.pbxproj:
527         * heap/CopiedSpace.h:
528         * heap/CopyVisitor.cpp:
529         (JSC::CopyVisitor::CopyVisitor):
530         (JSC::CopyVisitor::copyFromShared):
531         * heap/CopyVisitor.h:
532         * heap/CopyVisitorInlines.h:
533         (JSC::CopyVisitor::allocateNewSpaceSlow):
534         (JSC::CopyVisitor::startCopying):
535         (JSC::CopyVisitor::doneCopying):
536         (JSC::CopyVisitor::didCopy):
537         * heap/GCThread.cpp:
538         (JSC::GCThread::GCThread):
539         (JSC::GCThread::waitForNextPhase):
540         (JSC::GCThread::gcThreadMain):
541         * heap/GCThread.h:
542         * heap/GCThreadSharedData.cpp: Removed.
543         * heap/GCThreadSharedData.h: Removed.
544         * heap/Heap.cpp:
545         (JSC::Heap::Heap):
546         (JSC::Heap::~Heap):
547         (JSC::Heap::isPagedOut):
548         (JSC::Heap::markRoots):
549         (JSC::Heap::copyBackingStores):
550         (JSC::Heap::updateObjectCounts):
551         (JSC::Heap::resetVisitors):
552         (JSC::Heap::objectCount):
553         (JSC::Heap::sweepNextLogicallyEmptyWeakBlock):
554         (JSC::Heap::threadVisitCount):
555         (JSC::Heap::threadBytesVisited):
556         (JSC::Heap::threadBytesCopied):
557         (JSC::Heap::startNextPhase):
558         (JSC::Heap::endCurrentPhase):
559         * heap/Heap.h:
560         * heap/HeapInlines.h:
561         (JSC::Heap::unregisterWeakGCMap):
562         (JSC::Heap::getNextBlocksToCopy):
563         * heap/ListableHandler.h:
564         * heap/SlotVisitor.cpp:
565         (JSC::SlotVisitor::SlotVisitor):
566         (JSC::SlotVisitor::didStartMarking):
567         (JSC::SlotVisitor::reset):
568         (JSC::SlotVisitor::donateKnownParallel):
569         (JSC::SlotVisitor::drain):
570         (JSC::SlotVisitor::drainFromShared):
571         (JSC::SlotVisitor::mergeOpaqueRoots):
572         (JSC::SlotVisitor::harvestWeakReferences):
573         (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
574         * heap/SlotVisitor.h:
575         (JSC::SlotVisitor::markStack):
576         (JSC::SlotVisitor::isEmpty):
577         (JSC::SlotVisitor::sharedData): Deleted.
578         * heap/SlotVisitorInlines.h:
579         (JSC::SlotVisitor::addWeakReferenceHarvester):
580         (JSC::SlotVisitor::addUnconditionalFinalizer):
581         (JSC::SlotVisitor::addOpaqueRoot):
582         (JSC::SlotVisitor::containsOpaqueRoot):
583         (JSC::SlotVisitor::containsOpaqueRootTriState):
584         (JSC::SlotVisitor::opaqueRootCount):
585         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
586         (JSC::SlotVisitor::copyLater):
587         (JSC::SlotVisitor::heap):
588         (JSC::SlotVisitor::vm):
589
590 2015-09-22  Saam barati  <sbarati@apple.com>
591
592         Web Inspector: [ES6] Improve Type Profiler Support for Arrow Functions
593         https://bugs.webkit.org/show_bug.cgi?id=143171
594
595         Reviewed by Joseph Pecoraro.
596
597         We now need to take into account TypeProfilerSearchDescriptor when
598         hashing results for type profiler queries. Before, we've gotten
599         away with not doing this because before we would never have a text 
600         collision between a return type text offset and a normal expression text
601         offset. But, with arrow functions, we will have collisions when
602         the arrow function doesn't have parens around its single parameter.
603         I.e: "param => { ... };"
604
605         * runtime/TypeProfiler.cpp:
606         (JSC::TypeProfiler::findLocation):
607         * runtime/TypeProfiler.h:
608         (JSC::QueryKey::QueryKey):
609         (JSC::QueryKey::isHashTableDeletedValue):
610         (JSC::QueryKey::operator==):
611         (JSC::QueryKey::hash):
612         * tests/typeProfiler/arrow-functions.js: Added.
613
614 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
615
616         Get rid of ENABLE(PARALLEL_GC)
617         https://bugs.webkit.org/show_bug.cgi?id=149436
618
619         Reviewed by Mark Lam.
620
621         We always enable parallel GC everywhere but Windows, and it doesn't look like it was disabled
622         there for any good reason. So, get rid of the flag.
623
624         The only effect of this change is that parallel GC will now be enabled on Windows, provided
625         that the CPU detection finds more than one.
626
627         * heap/GCThread.cpp:
628         (JSC::GCThread::gcThreadMain):
629         * heap/GCThreadSharedData.cpp:
630         (JSC::GCThreadSharedData::resetChildren):
631         (JSC::GCThreadSharedData::childBytesCopied):
632         (JSC::GCThreadSharedData::GCThreadSharedData):
633         (JSC::GCThreadSharedData::~GCThreadSharedData):
634         (JSC::GCThreadSharedData::reset):
635         (JSC::GCThreadSharedData::didStartMarking):
636         * heap/Heap.cpp:
637         (JSC::Heap::converge):
638         (JSC::Heap::visitWeakHandles):
639         (JSC::Heap::updateObjectCounts):
640         (JSC::Heap::resetVisitors):
641         * heap/MarkedBlock.h:
642         * heap/SlotVisitor.cpp:
643         (JSC::SlotVisitor::didStartMarking):
644         (JSC::SlotVisitor::reset):
645         (JSC::SlotVisitor::drain):
646         (JSC::SlotVisitor::drainFromShared):
647         (JSC::SlotVisitor::mergeOpaqueRoots):
648         (JSC::JSString::tryHashConsLock):
649         (JSC::JSString::releaseHashConsLock):
650         * heap/SlotVisitorInlines.h:
651         (JSC::SlotVisitor::addOpaqueRoot):
652         (JSC::SlotVisitor::containsOpaqueRoot):
653         (JSC::SlotVisitor::containsOpaqueRootTriState):
654         (JSC::SlotVisitor::opaqueRootCount):
655         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
656         * runtime/Options.cpp:
657         (JSC::computeNumberOfGCMarkers):
658
659 2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
660
661         Implement min and max instructions in WebAssembly
662         https://bugs.webkit.org/show_bug.cgi?id=149454
663
664         Reviewed by Geoffrey Garen.
665
666         This patch implements min and max instructions in WebAssembly.
667
668         * tests/stress/wasm-arithmetic-float64.js:
669         * tests/stress/wasm-arithmetic-int32.js:
670         * tests/stress/wasm/arithmetic-float64.wasm:
671         * tests/stress/wasm/arithmetic-int32.wasm:
672         * wasm/WASMFunctionCompiler.h:
673         (JSC::WASMFunctionCompiler::buildMinOrMaxI32):
674         (JSC::WASMFunctionCompiler::buildMinOrMaxF64):
675         * wasm/WASMFunctionParser.cpp:
676         (JSC::WASMFunctionParser::parseExpressionI32):
677         (JSC::WASMFunctionParser::parseMinOrMaxExpressionI32):
678         (JSC::WASMFunctionParser::parseExpressionF64):
679         (JSC::WASMFunctionParser::parseMinOrMaxExpressionF64):
680         * wasm/WASMFunctionParser.h:
681         * wasm/WASMFunctionSyntaxChecker.h:
682         (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxI32):
683         (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxF64):
684
685 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
686
687         Get rid of ENABLE(GGC)
688         https://bugs.webkit.org/show_bug.cgi?id=149472
689
690         Reviewed by Mark Hahnenberg and Mark Lam.
691
692         Getting rid of this feature flag allows us to remove a lot of yuck.
693
694         * bytecode/CodeBlock.h:
695         (JSC::CodeBlockSet::mark):
696         (JSC::ScriptExecutable::forEachCodeBlock):
697         * bytecode/PolymorphicAccess.cpp:
698         (JSC::AccessCase::generate):
699         * dfg/DFGOSRExitCompilerCommon.cpp:
700         (JSC::DFG::reifyInlinedCallFrames):
701         (JSC::DFG::osrWriteBarrier):
702         (JSC::DFG::adjustAndJumpToTarget):
703         * dfg/DFGSpeculativeJIT.cpp:
704         (JSC::DFG::SpeculativeJIT::linkBranches):
705         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
706         (JSC::DFG::SpeculativeJIT::writeBarrier):
707         * dfg/DFGSpeculativeJIT.h:
708         (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
709         (JSC::DFG::SpeculativeJIT::selectScratchGPR):
710         * dfg/DFGSpeculativeJIT32_64.cpp:
711         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
712         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
713         (JSC::DFG::SpeculativeJIT::compile):
714         (JSC::DFG::SpeculativeJIT::writeBarrier):
715         (JSC::DFG::SpeculativeJIT::moveTrueTo):
716         * dfg/DFGSpeculativeJIT64.cpp:
717         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
718         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
719         (JSC::DFG::SpeculativeJIT::compile):
720         (JSC::DFG::SpeculativeJIT::writeBarrier):
721         (JSC::DFG::SpeculativeJIT::moveTrueTo):
722         * ftl/FTLLowerDFGToLLVM.cpp:
723         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
724         * heap/CodeBlockSet.cpp:
725         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
726         (JSC::CodeBlockSet::dump):
727         * heap/Heap.cpp:
728         (JSC::Heap::Heap):
729         (JSC::Heap::markRoots):
730         (JSC::Heap::clearRememberedSet):
731         (JSC::Heap::updateObjectCounts):
732         (JSC::Heap::flushWriteBarrierBuffer):
733         (JSC::Heap::shouldDoFullCollection):
734         (JSC::Heap::addLogicallyEmptyWeakBlock):
735         * heap/HeapInlines.h:
736         (JSC::Heap::isWriteBarrierEnabled):
737         (JSC::Heap::writeBarrier):
738         (JSC::Heap::reportExtraMemoryAllocated):
739         (JSC::Heap::reportExtraMemoryVisited):
740         * heap/MarkedBlock.cpp:
741         (JSC::MarkedBlock::clearMarks):
742         * heap/MarkedSpace.cpp:
743         (JSC::MarkedSpace::resetAllocators):
744         (JSC::MarkedSpace::visitWeakSets):
745         * heap/MarkedSpace.h:
746         (JSC::MarkedSpace::didAllocateInBlock):
747         (JSC::MarkedSpace::objectCount):
748         * jit/JITPropertyAccess.cpp:
749         (JSC::JIT::emitWriteBarrier):
750         (JSC::JIT::emitIdentifierCheck):
751         (JSC::JIT::privateCompilePutByVal):
752         * llint/LLIntOfflineAsmConfig.h:
753         * llint/LowLevelInterpreter32_64.asm:
754         * llint/LowLevelInterpreter64.asm:
755
756 2015-09-22  Saam barati  <sbarati@apple.com>
757
758         the toInt32 operation inside DFGSpeculativeJIT.cpp can't throw so we shouldn't emit an exceptionCheck after it.
759         https://bugs.webkit.org/show_bug.cgi?id=149467
760
761         Reviewed by Mark Lam.
762
763         The callOperation for toInt32 won't store a call site index in the call frame.
764         Therefore, if this is the first callOperation in the current compilation, 
765         and we emit an exception check inside a try block, we will hit an assertion 
766         saying that we must have DFGCommonData::codeOrigins.size() be > 0 inside
767         DFGCommonData::lastCallSite(). Therefore, it is imperative that we don't 
768         emit exception checks for callOperations that don't throw exceptions and 
769         don't store a call site index in the call frame.
770
771         * dfg/DFGCommonData.cpp:
772         (JSC::DFG::CommonData::lastCallSite):
773         * dfg/DFGSpeculativeJIT.cpp:
774         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
775         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
776
777 2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
778
779         Implement the conditional instruction in WebAssembly
780         https://bugs.webkit.org/show_bug.cgi?id=149451
781
782         Reviewed by Geoffrey Garen.
783
784         This patch implements the conditional (ternary) instruction in WebAssembly.
785         This is basically "condition ? exp1 : exp2" in JavaScript.
786         
787         The use of context.discard() in WASMFunctionParser::parseConditional()
788         is not ideal. We don't discard anything. We just use it to decrement the
789         stack top in the WebAssembly baseline JIT. When we optimize the JIT by
790         storing results directly into the destination like the JavaScript
791         baseline JIT, the code will look like this:
792
793             ContextExpression temp = context.newTemporary();
794             ContextExpression condition = parseExpressionI32(context);
795             context.jumpToTargetIf(Context::JumpCondition::Zero, condition, elseTarget);
796
797             parseExpression(context, temp, expressionType);
798             context.jumpToTarget(end);
799
800             context.linkTarget(elseTarget);
801             parseExpression(context, temp, expressionType);
802             context.linkTarget(end);
803
804             return temp;
805
806         which looks cleaner than using discard().
807
808         * tests/stress/wasm-control-flow.js:
809         * tests/stress/wasm/control-flow.wasm:
810         * wasm/WASMFunctionParser.cpp:
811         (JSC::WASMFunctionParser::parseExpressionI32):
812         (JSC::WASMFunctionParser::parseExpressionF32):
813         (JSC::WASMFunctionParser::parseExpressionF64):
814         (JSC::WASMFunctionParser::parseConditional):
815         * wasm/WASMFunctionParser.h:
816
817 2015-09-22  Commit Queue  <commit-queue@webkit.org>
818
819         Unreviewed, rolling out r189616.
820         https://bugs.webkit.org/show_bug.cgi?id=149456
821
822         suspected cause of multiple regressions (Requested by kling on
823         #webkit).
824
825         Reverted changeset:
826
827         "[JSC] Weak should only accept cell pointees."
828         https://bugs.webkit.org/show_bug.cgi?id=148955
829         http://trac.webkit.org/changeset/189616
830
831 2015-09-22  Saam barati  <sbarati@apple.com>
832
833         Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
834         https://bugs.webkit.org/show_bug.cgi?id=149248
835
836         Reviewed by Mark Lam.
837
838         We keep track of which functions have and have not
839         executed so we can show visually, inside the inspector,
840         which functions have and have not executed. With a default
841         constructor, our parser parses code that isn't in the actual
842         JavaScript source code of the user. Our parser would then
843         give us a range of starting at "1" to "1 + default constructor length"
844         as being the text range of a function. But, this would then pollute
845         actual source code that was at these ranges.
846
847         Therefore, we should treat these default constructor source 
848         codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
849         as the invalid range. This range has the effect of not polluting 
850         valid ranges inside the source code.
851
852         * bytecode/UnlinkedFunctionExecutable.cpp:
853         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
854         (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
855         * bytecode/UnlinkedFunctionExecutable.h:
856         * bytecompiler/BytecodeGenerator.cpp:
857         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
858
859 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
860
861         Implement the comma instruction in WebAssembly
862         https://bugs.webkit.org/show_bug.cgi?id=149425
863
864         Reviewed by Geoffrey Garen.
865
866         This patch implements the comma instruction in WebAssembly. The comma
867         instruction evaluates the left operand and then the right operand and
868         returns the value of the right operand.
869
870         * tests/stress/wasm-comma.js: Added.
871         (shouldBe):
872         * wasm/WASMFunctionCompiler.h:
873         (JSC::WASMFunctionCompiler::discard):
874         * wasm/WASMFunctionParser.cpp:
875         (JSC::WASMFunctionParser::parseExpressionI32):
876         (JSC::WASMFunctionParser::parseExpressionF32):
877         (JSC::WASMFunctionParser::parseExpressionF64):
878         (JSC::WASMFunctionParser::parseComma):
879         * wasm/WASMFunctionParser.h:
880         * wasm/WASMFunctionSyntaxChecker.h:
881         (JSC::WASMFunctionSyntaxChecker::discard):
882
883 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
884
885         Always use the compiler's CAS implementation and get rid of ENABLE(COMPARE_AND_SWAP)
886         https://bugs.webkit.org/show_bug.cgi?id=149438
887
888         Reviewed by Mark Lam.
889
890         * heap/HeapInlines.h:
891         (JSC::Heap::reportExtraMemoryVisited):
892         (JSC::Heap::deprecatedReportExtraMemory):
893
894 2015-09-21  Saam barati  <sbarati@apple.com>
895
896         functionProtoFuncToString should not rely on typeProfilingEndOffset()
897         https://bugs.webkit.org/show_bug.cgi?id=149429
898
899         Reviewed by Geoffrey Garen.
900
901         We should be able to freely change typeProfilingEndOffset()
902         without worrying we will break Function.prototype.toString.
903
904         * runtime/FunctionPrototype.cpp:
905         (JSC::functionProtoFuncToString):
906
907 2015-09-21  Commit Queue  <commit-queue@webkit.org>
908
909         Unreviewed, rolling out r190086.
910         https://bugs.webkit.org/show_bug.cgi?id=149427
911
912         Broke LayoutTests/inspector/model/remote-object.htm (Requested
913         by saamyjoon on #webkit).
914
915         Reverted changeset:
916
917         "Web Inspector: Basic Block Annotations and Type Profiler
918         annotations wrong for script with "class" with default
919         constructor"
920         https://bugs.webkit.org/show_bug.cgi?id=149248
921         http://trac.webkit.org/changeset/190086
922
923 2015-09-21  Saam barati  <sbarati@apple.com>
924
925         Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
926         https://bugs.webkit.org/show_bug.cgi?id=149248
927
928         Reviewed by Mark Lam.
929
930         We keep track of which functions have and have not
931         executed so we can show visually, inside the inspector,
932         which functions have and have not executed. With a default
933         constructor, our parser parses code that isn't in the actual
934         JavaScript source code of the user. Our parser would then
935         give us a range of starting at "1" to "1 + default constructor length"
936         as being the text range of a function. But, this would then pollute
937         actual source code that was at these ranges.
938
939         Therefore, we should treat these default constructor source 
940         codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
941         as the invalid range. This range has the effect of not polluting 
942         valid ranges inside the source code.
943
944         * bytecode/UnlinkedFunctionExecutable.cpp:
945         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
946         (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
947         * bytecode/UnlinkedFunctionExecutable.h:
948         * bytecompiler/BytecodeGenerator.cpp:
949         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
950
951 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
952
953         Implement call statements and call expressions of type void in WebAssembly
954         https://bugs.webkit.org/show_bug.cgi?id=149411
955
956         Reviewed by Mark Lam.
957
958         Call instructions in WebAssembly can be both statements and expressions.
959         This patch implements call statements. It also implements call
960         expressions of type void. The only place where call expressions of type
961         void can occur is the left-hand side of the comma (,) operator, which
962         will be implemented in a subsequent patch. The comma operator requires
963         both of its operands to be expressions.
964
965         * tests/stress/wasm-calls.js:
966         * tests/stress/wasm/calls.wasm:
967         * wasm/WASMConstants.h:
968         * wasm/WASMFunctionParser.cpp:
969         (JSC::WASMFunctionParser::parseStatement):
970         (JSC::WASMFunctionParser::parseExpression):
971         (JSC::WASMFunctionParser::parseExpressionI32):
972         (JSC::WASMFunctionParser::parseExpressionF32):
973         (JSC::WASMFunctionParser::parseExpressionF64):
974         (JSC::WASMFunctionParser::parseExpressionVoid):
975         (JSC::WASMFunctionParser::parseCallInternal):
976         (JSC::WASMFunctionParser::parseCallIndirect):
977         (JSC::WASMFunctionParser::parseCallImport):
978         * wasm/WASMFunctionParser.h:
979         * wasm/WASMReader.cpp:
980         (JSC::WASMReader::readOpExpressionVoid):
981         * wasm/WASMReader.h:
982
983 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
984
985         JSC should infer property types
986         https://bugs.webkit.org/show_bug.cgi?id=148610
987
988         Reviewed by Geoffrey Garen.
989
990         This change brings recursive type inference to JavaScript object properties in JSC. We check that a
991         value being stored into a property obeys a property's type before we do the store. If it doesn't,
992         we broaden the property's type to include the new value. If optimized code was relying on the old
993         type, we deoptimize that code.
994
995         The type system that this supports includes important primitive types like Int32 and Boolean. But
996         it goes further and also includes a type kind called ObjectWithStructure, which means that we
997         expect the property to always point to objects with a particular structure. This only works for
998         leaf structures (i.e. structures that have a valid transition watchpoint set). Invalidation of the
999         transition set causes the property type to become Object (meaning an object with any structure).
1000         This capability gives us recursive type inference. It's possible for an expression like "o.f.g.h"
1001         to execute without any type checks if .f and .g are both ObjectWithStructure.
1002
1003         The type inference of a property is tracked by an InferredType instance, which is a JSCell. This
1004         means that it manages its own memory. That's convenient. For example, when the DFG is interested in
1005         one of these, it can just list the InferredType as a weak reference in addition to setting a
1006         watchpoint. This ensures that even if the InferredType is dropped by the owning structure, the DFG
1007         won't read a dangling pointer. A mapping from property name to InferredType is implemented by
1008         InferredTypeTable, which is also a JSCell. Each Structure may point to some InferredTypeTable.
1009
1010         This feature causes programs to be happier (run faster without otherwise doing bad things like
1011         using lots of memory) when four conditions hold:
1012
1013         1) A property converges to one of the types that we support.
1014         2) The property is loaded from more frequently than it is stored to.
1015         3) The stores are all cached, so that we statically emit a type check.
1016         4) We don't allocate a lot of meta-data for the property's type.
1017
1018         We maximize the likelihood of (1) by having a rich type system. But having a rich type system means
1019         that a reflective put to a property has to have a large switch over the inferred type to decide how
1020         to do the type check. That's why we need (3). We ensure (3) by having every reflective property
1021         store (i.e. putDirectInternal in any context that isn't PutById) force the inferred type to become
1022         Top. We don't really worry about ensuring (2); this is statistically true for most programs
1023         already.
1024
1025         Probably the most subtle trickery goes into (4). Logically we'd like to say that each
1026         (Structure, Property) maps to its own InferredType. If structure S1 has a transition edge to S2,
1027         then we could ensure that the InferredType I1 where (S1, Property)->I1 has a data flow constraint
1028         to I2 where (S2, Property)->I2. That would work, but it would involve a lot of memory. And when I1
1029         gets invalidated in some way, it would have to tell I2 about it, and then I2 might tell other
1030         InferredType objects downstream. That's madness. So, the first major compromise that we make here
1031         is to say that if some property has some InferredType at some Structure, then anytime we
1032         transition from that Structure, the new Structure shares the same InferredType for that property.
1033         This unifies the type of the property over the entire transition tree starting at the Structure at
1034         which the property was added. But this would still mean that each Structure would have its own
1035         InferredTypeTable. We don't want that because experience with PropertyTable shows that this can be
1036         a major memory hog. So, we don't create an InferredTypeTable until someone adds a property that is
1037         subject to type inference (i.e. it was added non-reflectively), and we share that InferredTypeTable
1038         with the entire structure transition tree rooted at the Structure that had the first inferred
1039         property. We also drop the InferredTypeTable anytime that we do a dictionary transition, and we
1040         don't allow further property type inference if a structure had ever been a dictionary.
1041
1042         This is a 3% speed-up on Octane and a 12% speed-up on Kraken on my setup. It's not a significant
1043         slow-down on any benchmark I ran.
1044
1045         * CMakeLists.txt:
1046         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1047         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1048         * JavaScriptCore.xcodeproj/project.pbxproj:
1049         * assembler/MacroAssemblerARM64.h:
1050         (JSC::MacroAssemblerARM64::branchTest64):
1051         * assembler/MacroAssemblerX86_64.h:
1052         (JSC::MacroAssemblerX86_64::branchTest64):
1053         (JSC::MacroAssemblerX86_64::test64):
1054         * bytecode/PolymorphicAccess.cpp:
1055         (JSC::AccessCase::generate):
1056         * bytecode/PutByIdFlags.cpp:
1057         (WTF::printInternal):
1058         * bytecode/PutByIdFlags.h:
1059         (JSC::encodeStructureID):
1060         (JSC::decodeStructureID):
1061         * bytecode/PutByIdStatus.cpp:
1062         (JSC::PutByIdStatus::computeFromLLInt):
1063         (JSC::PutByIdStatus::computeFor):
1064         (JSC::PutByIdStatus::computeForStubInfo):
1065         * bytecode/PutByIdVariant.cpp:
1066         (JSC::PutByIdVariant::operator=):
1067         (JSC::PutByIdVariant::replace):
1068         (JSC::PutByIdVariant::transition):
1069         (JSC::PutByIdVariant::setter):
1070         (JSC::PutByIdVariant::attemptToMerge):
1071         (JSC::PutByIdVariant::dumpInContext):
1072         * bytecode/PutByIdVariant.h:
1073         (JSC::PutByIdVariant::newStructure):
1074         (JSC::PutByIdVariant::requiredType):
1075         * bytecode/UnlinkedCodeBlock.h:
1076         (JSC::UnlinkedInstruction::UnlinkedInstruction):
1077         * bytecode/Watchpoint.h:
1078         (JSC::InlineWatchpointSet::touch):
1079         (JSC::InlineWatchpointSet::isBeingWatched):
1080         * bytecompiler/BytecodeGenerator.cpp:
1081         (JSC::BytecodeGenerator::addConstantValue):
1082         (JSC::BytecodeGenerator::emitPutById):
1083         (JSC::BytecodeGenerator::emitDirectPutById):
1084         * dfg/DFGAbstractInterpreter.h:
1085         (JSC::DFG::AbstractInterpreter::filter):
1086         (JSC::DFG::AbstractInterpreter::filterByValue):
1087         * dfg/DFGAbstractInterpreterInlines.h:
1088         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1089         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
1090         * dfg/DFGAbstractValue.cpp:
1091         (JSC::DFG::AbstractValue::setType):
1092         (JSC::DFG::AbstractValue::set):
1093         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
1094         (JSC::DFG::AbstractValue::mergeOSREntryValue):
1095         (JSC::DFG::AbstractValue::isType):
1096         (JSC::DFG::AbstractValue::filter):
1097         (JSC::DFG::AbstractValue::filterValueByType):
1098         * dfg/DFGAbstractValue.h:
1099         (JSC::DFG::AbstractValue::setType):
1100         (JSC::DFG::AbstractValue::isType):
1101         (JSC::DFG::AbstractValue::validate):
1102         * dfg/DFGByteCodeParser.cpp:
1103         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1104         (JSC::DFG::ByteCodeParser::handleGetByOffset):
1105         (JSC::DFG::ByteCodeParser::handlePutByOffset):
1106         (JSC::DFG::ByteCodeParser::load):
1107         (JSC::DFG::ByteCodeParser::store):
1108         (JSC::DFG::ByteCodeParser::handleGetById):
1109         (JSC::DFG::ByteCodeParser::handlePutById):
1110         * dfg/DFGClobbersExitState.cpp:
1111         (JSC::DFG::clobbersExitState):
1112         * dfg/DFGConstantFoldingPhase.cpp:
1113         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1114         (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
1115         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
1116         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
1117         * dfg/DFGDesiredInferredType.h: Added.
1118         (JSC::DFG::DesiredInferredType::DesiredInferredType):
1119         (JSC::DFG::DesiredInferredType::operator bool):
1120         (JSC::DFG::DesiredInferredType::object):
1121         (JSC::DFG::DesiredInferredType::expected):
1122         (JSC::DFG::DesiredInferredType::isStillValid):
1123         (JSC::DFG::DesiredInferredType::add):
1124         (JSC::DFG::DesiredInferredType::operator==):
1125         (JSC::DFG::DesiredInferredType::operator!=):
1126         (JSC::DFG::DesiredInferredType::isHashTableDeletedValue):
1127         (JSC::DFG::DesiredInferredType::hash):
1128         (JSC::DFG::DesiredInferredType::dumpInContext):
1129         (JSC::DFG::DesiredInferredType::dump):
1130         (JSC::DFG::DesiredInferredTypeHash::hash):
1131         (JSC::DFG::DesiredInferredTypeHash::equal):
1132         * dfg/DFGDesiredWatchpoints.cpp:
1133         (JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
1134         (JSC::DFG::InferredTypeAdaptor::add):
1135         (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
1136         (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
1137         (JSC::DFG::DesiredWatchpoints::addLazily):
1138         (JSC::DFG::DesiredWatchpoints::consider):
1139         (JSC::DFG::DesiredWatchpoints::reallyAdd):
1140         (JSC::DFG::DesiredWatchpoints::areStillValid):
1141         (JSC::DFG::DesiredWatchpoints::dumpInContext):
1142         * dfg/DFGDesiredWatchpoints.h:
1143         (JSC::DFG::AdaptiveStructureWatchpointAdaptor::dumpInContext):
1144         (JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated):
1145         (JSC::DFG::InferredTypeAdaptor::dumpInContext):
1146         (JSC::DFG::DesiredWatchpoints::isWatched):
1147         * dfg/DFGFixupPhase.cpp:
1148         (JSC::DFG::FixupPhase::fixupNode):
1149         * dfg/DFGGraph.cpp:
1150         (JSC::DFG::Graph::dump):
1151         (JSC::DFG::Graph::isSafeToLoad):
1152         (JSC::DFG::Graph::inferredTypeFor):
1153         (JSC::DFG::Graph::livenessFor):
1154         (JSC::DFG::Graph::tryGetConstantProperty):
1155         (JSC::DFG::Graph::inferredValueForProperty):
1156         (JSC::DFG::Graph::tryGetConstantClosureVar):
1157         * dfg/DFGGraph.h:
1158         (JSC::DFG::Graph::registerInferredType):
1159         (JSC::DFG::Graph::inferredTypeForProperty):
1160         * dfg/DFGInferredTypeCheck.cpp: Added.
1161         (JSC::DFG::insertInferredTypeCheck):
1162         * dfg/DFGInferredTypeCheck.h: Added.
1163         * dfg/DFGNode.h:
1164         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1165         * dfg/DFGPropertyTypeKey.h: Added.
1166         (JSC::DFG::PropertyTypeKey::PropertyTypeKey):
1167         (JSC::DFG::PropertyTypeKey::operator bool):
1168         (JSC::DFG::PropertyTypeKey::structure):
1169         (JSC::DFG::PropertyTypeKey::uid):
1170         (JSC::DFG::PropertyTypeKey::operator==):
1171         (JSC::DFG::PropertyTypeKey::operator!=):
1172         (JSC::DFG::PropertyTypeKey::hash):
1173         (JSC::DFG::PropertyTypeKey::isHashTableDeletedValue):
1174         (JSC::DFG::PropertyTypeKey::dumpInContext):
1175         (JSC::DFG::PropertyTypeKey::dump):
1176         (JSC::DFG::PropertyTypeKey::deletedUID):
1177         (JSC::DFG::PropertyTypeKeyHash::hash):
1178         (JSC::DFG::PropertyTypeKeyHash::equal):
1179         * dfg/DFGSafeToExecute.h:
1180         (JSC::DFG::SafeToExecuteEdge::operator()):
1181         (JSC::DFG::safeToExecute):
1182         * dfg/DFGSpeculativeJIT.cpp:
1183         (JSC::DFG::SpeculativeJIT::compileTypeOf):
1184         (JSC::DFG::SpeculativeJIT::compileCheckStructure):
1185         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
1186         (JSC::DFG::SpeculativeJIT::speculateCell):
1187         (JSC::DFG::SpeculativeJIT::speculateCellOrOther):
1188         (JSC::DFG::SpeculativeJIT::speculateObject):
1189         (JSC::DFG::SpeculativeJIT::speculate):
1190         * dfg/DFGSpeculativeJIT.h:
1191         * dfg/DFGSpeculativeJIT32_64.cpp:
1192         (JSC::DFG::SpeculativeJIT::compile):
1193         * dfg/DFGSpeculativeJIT64.cpp:
1194         (JSC::DFG::SpeculativeJIT::compile):
1195         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1196         * dfg/DFGStructureAbstractValue.h:
1197         (JSC::DFG::StructureAbstractValue::at):
1198         (JSC::DFG::StructureAbstractValue::operator[]):
1199         (JSC::DFG::StructureAbstractValue::onlyStructure):
1200         (JSC::DFG::StructureAbstractValue::forEach):
1201         * dfg/DFGUseKind.cpp:
1202         (WTF::printInternal):
1203         * dfg/DFGUseKind.h:
1204         (JSC::DFG::typeFilterFor):
1205         * dfg/DFGValidate.cpp:
1206         (JSC::DFG::Validate::validate):
1207         * ftl/FTLCapabilities.cpp:
1208         (JSC::FTL::canCompile):
1209         * ftl/FTLLowerDFGToLLVM.cpp:
1210         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckStructure):
1211         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckCell):
1212         (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
1213         (JSC::FTL::DFG::LowerDFGToLLVM::numberOrNotCellToInt32):
1214         (JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
1215         (JSC::FTL::DFG::LowerDFGToLLVM::loadProperty):
1216         (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
1217         (JSC::FTL::DFG::LowerDFGToLLVM::speculateCell):
1218         (JSC::FTL::DFG::LowerDFGToLLVM::speculateCellOrOther):
1219         (JSC::FTL::DFG::LowerDFGToLLVM::speculateMachineInt):
1220         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
1221         * jit/AssemblyHelpers.cpp:
1222         (JSC::AssemblyHelpers::decodedCodeMapFor):
1223         (JSC::AssemblyHelpers::branchIfNotType):
1224         (JSC::AssemblyHelpers::purifyNaN):
1225         * jit/AssemblyHelpers.h:
1226         (JSC::AssemblyHelpers::branchIfEqual):
1227         (JSC::AssemblyHelpers::branchIfNotCell):
1228         (JSC::AssemblyHelpers::branchIfCell):
1229         (JSC::AssemblyHelpers::branchIfNotOther):
1230         (JSC::AssemblyHelpers::branchIfInt32):
1231         (JSC::AssemblyHelpers::branchIfNotInt32):
1232         (JSC::AssemblyHelpers::branchIfNumber):
1233         (JSC::AssemblyHelpers::branchIfNotNumber):
1234         (JSC::AssemblyHelpers::branchIfEmpty):
1235         (JSC::AssemblyHelpers::branchStructure):
1236         * jit/Repatch.cpp:
1237         (JSC::tryCachePutByID):
1238         * llint/LLIntSlowPaths.cpp:
1239         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1240         * llint/LowLevelInterpreter.asm:
1241         * llint/LowLevelInterpreter32_64.asm:
1242         * llint/LowLevelInterpreter64.asm:
1243         * runtime/InferredType.cpp: Added.
1244         (JSC::InferredType::create):
1245         (JSC::InferredType::destroy):
1246         (JSC::InferredType::createStructure):
1247         (JSC::InferredType::visitChildren):
1248         (JSC::InferredType::kindForFlags):
1249         (JSC::InferredType::Descriptor::forValue):
1250         (JSC::InferredType::Descriptor::forFlags):
1251         (JSC::InferredType::Descriptor::putByIdFlags):
1252         (JSC::InferredType::Descriptor::merge):
1253         (JSC::InferredType::Descriptor::removeStructure):
1254         (JSC::InferredType::Descriptor::subsumes):
1255         (JSC::InferredType::Descriptor::dumpInContext):
1256         (JSC::InferredType::Descriptor::dump):
1257         (JSC::InferredType::InferredType):
1258         (JSC::InferredType::~InferredType):
1259         (JSC::InferredType::canWatch):
1260         (JSC::InferredType::addWatchpoint):
1261         (JSC::InferredType::dump):
1262         (JSC::InferredType::willStoreValueSlow):
1263         (JSC::InferredType::makeTopSlow):
1264         (JSC::InferredType::set):
1265         (JSC::InferredType::removeStructure):
1266         (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
1267         (JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally):
1268         (JSC::InferredType::InferredStructure::InferredStructure):
1269         (WTF::printInternal):
1270         * runtime/InferredType.h: Added.
1271         * runtime/InferredTypeTable.cpp: Added.
1272         (JSC::InferredTypeTable::create):
1273         (JSC::InferredTypeTable::destroy):
1274         (JSC::InferredTypeTable::createStructure):
1275         (JSC::InferredTypeTable::visitChildren):
1276         (JSC::InferredTypeTable::get):
1277         (JSC::InferredTypeTable::willStoreValue):
1278         (JSC::InferredTypeTable::makeTop):
1279         (JSC::InferredTypeTable::InferredTypeTable):
1280         (JSC::InferredTypeTable::~InferredTypeTable):
1281         * runtime/InferredTypeTable.h: Added.
1282         * runtime/JSObject.h:
1283         (JSC::JSObject::putDirectInternal):
1284         (JSC::JSObject::putDirectWithoutTransition):
1285         * runtime/Structure.cpp:
1286         (JSC::Structure::materializePropertyMap):
1287         (JSC::Structure::addPropertyTransition):
1288         (JSC::Structure::removePropertyTransition):
1289         (JSC::Structure::startWatchingInternalProperties):
1290         (JSC::Structure::willStoreValueSlow):
1291         (JSC::Structure::visitChildren):
1292         (JSC::Structure::prototypeChainMayInterceptStoreTo):
1293         * runtime/Structure.h:
1294         (JSC::PropertyMapEntry::PropertyMapEntry):
1295         * runtime/StructureInlines.h:
1296         (JSC::Structure::get):
1297         * runtime/VM.cpp:
1298         (JSC::VM::VM):
1299         * runtime/VM.h:
1300         * tests/stress/prop-type-boolean-then-string.js: Added.
1301         * tests/stress/prop-type-int32-then-string.js: Added.
1302         * tests/stress/prop-type-number-then-string.js: Added.
1303         * tests/stress/prop-type-object-or-other-then-string.js: Added.
1304         * tests/stress/prop-type-object-then-string.js: Added.
1305         * tests/stress/prop-type-other-then-string.js: Added.
1306         * tests/stress/prop-type-string-then-object.js: Added.
1307         * tests/stress/prop-type-struct-or-other-then-string.js: Added.
1308         * tests/stress/prop-type-struct-then-object.js: Added.
1309         * tests/stress/prop-type-struct-then-object-opt.js: Added.
1310         * tests/stress/prop-type-struct-then-object-opt-fold.js: Added.
1311         * tests/stress/prop-type-struct-then-object-opt-multi.js: Added.
1312
1313 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
1314
1315         WebCore shouldn't have to include DFG headers
1316         https://bugs.webkit.org/show_bug.cgi?id=149337
1317
1318         Reviewed by Michael Saboff.
1319
1320         This does some simple rewiring and outlining of CodeBlock/Heap functionality so that
1321         those headers don't have to include DFG headers. As a result, WebCore no longer includes
1322         DFG headers, except for two fairly innocent ones (DFGCommon.h and DFGCompilationMode.h).
1323         This also changes the Xcode project file so that all but those two headers are Project
1324         rather than Private. So, if WebCore accidentally includes any of them, we'll get a build
1325         error.
1326
1327         The main group of headers that this prevents WebCore from including are the DFGDesired*.h
1328         files and whatever those include. Those headers used to be fairly simple, but now they
1329         are growing in complexity (especially with things like http://webkit.org/b/148610). So,
1330         it makes sense to make sure they don't leak out of JSC.
1331
1332         * JavaScriptCore.xcodeproj/project.pbxproj:
1333         * bytecode/CallLinkInfo.cpp:
1334         (JSC::CallLinkInfo::CallLinkInfo):
1335         (JSC::CallLinkInfo::~CallLinkInfo):
1336         (JSC::CallLinkInfo::clearStub):
1337         (JSC::CallLinkInfo::visitWeak):
1338         (JSC::CallLinkInfo::setFrameShuffleData):
1339         * bytecode/CallLinkInfo.h:
1340         (JSC::CallLinkInfo::isVarargsCallType):
1341         (JSC::CallLinkInfo::specializationKindFor):
1342         (JSC::CallLinkInfo::frameShuffleData):
1343         (JSC::CallLinkInfo::CallLinkInfo): Deleted.
1344         (JSC::CallLinkInfo::~CallLinkInfo): Deleted.
1345         (JSC::CallLinkInfo::setFrameShuffleData): Deleted.
1346         * bytecode/CodeBlock.cpp:
1347         (JSC::CodeBlock::getOrAddArrayProfile):
1348         (JSC::CodeBlock::codeOrigins):
1349         (JSC::CodeBlock::numberOfDFGIdentifiers):
1350         (JSC::CodeBlock::identifier):
1351         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
1352         * bytecode/CodeBlock.h:
1353         (JSC::CodeBlock::hasExpressionInfo):
1354         (JSC::CodeBlock::hasCodeOrigins):
1355         (JSC::CodeBlock::numberOfIdentifiers):
1356         (JSC::CodeBlock::identifier):
1357         (JSC::CodeBlock::codeOrigins): Deleted.
1358         (JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
1359         * bytecode/CodeOrigin.h:
1360         * dfg/DFGDesiredIdentifiers.cpp:
1361         * heap/Heap.cpp:
1362         (JSC::Heap::didFinishIterating):
1363         (JSC::Heap::completeAllDFGPlans):
1364         (JSC::Heap::markRoots):
1365         (JSC::Heap::deleteAllCodeBlocks):
1366         * heap/Heap.h:
1367         * heap/HeapInlines.h:
1368         (JSC::Heap::deprecatedReportExtraMemory):
1369         (JSC::Heap::forEachCodeBlock):
1370         (JSC::Heap::forEachProtectedCell):
1371         * runtime/Executable.h:
1372         * runtime/JSCInlines.h:
1373         (JSC::Heap::forEachCodeBlock): Deleted.
1374
1375 2015-09-21 Aleksandr Skachkov   <gskachkov@gmail.com>
1376
1377         Web Inspector: arrow function names are never inferred, call frames are labeled (anonymous function)
1378         https://bugs.webkit.org/show_bug.cgi?id=148318
1379
1380         Reviewed by Saam Barati.
1381
1382         Tiny change to support of the inferred name in arrow function
1383  
1384         * parser/ASTBuilder.h:
1385         (JSC::ASTBuilder::createAssignResolve):
1386
1387 2015-09-19 Aleksandr Skachkov   <gskachkov@gmail.com>
1388
1389         New tests introduced in r188545 fail on 32 bit ARM
1390         https://bugs.webkit.org/show_bug.cgi?id=148376
1391
1392         Reviewed by Saam Barati.
1393
1394         Added correct support of the ARM CPU in JIT functions that are related to arrow function.
1395
1396
1397         * dfg/DFGSpeculativeJIT.cpp:
1398         (JSC::DFG::SpeculativeJIT::compileNewFunction):
1399         * dfg/DFGSpeculativeJIT.h:
1400         (JSC::DFG::SpeculativeJIT::callOperation):
1401         * jit/JIT.h:
1402         * jit/JITInlines.h:
1403         (JSC::JIT::callOperation):
1404         * jit/JITOpcodes.cpp:
1405         (JSC::JIT::emitNewFuncExprCommon):
1406
1407 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1408
1409         Implement Store expressions in WebAssembly
1410         https://bugs.webkit.org/show_bug.cgi?id=149395
1411
1412         Reviewed by Geoffrey Garen.
1413
1414         The Store instruction in WebAssembly stores a value in the linear memory
1415         at the given index. It can be both a statement and an expression. When
1416         it is an expression, it returns the assigned value. This patch
1417         implements Store as an expression.
1418
1419         Since Store uses two operands, which are the index and the value, we
1420         need to pop the two operands from the stack and push the value back to
1421         the stack. We can simply implement this by copying the value to where
1422         the index is in the stack.
1423
1424         * tests/stress/wasm-linear-memory.js:
1425         * wasm/WASMFunctionCompiler.h:
1426         (JSC::WASMFunctionCompiler::buildStore):
1427         * wasm/WASMFunctionParser.cpp:
1428         (JSC::WASMFunctionParser::parseStatement):
1429         (JSC::WASMFunctionParser::parseExpressionI32):
1430         (JSC::WASMFunctionParser::parseExpressionF32):
1431         (JSC::WASMFunctionParser::parseExpressionF64):
1432         (JSC::WASMFunctionParser::parseStore):
1433         * wasm/WASMFunctionParser.h:
1434         * wasm/WASMFunctionSyntaxChecker.h:
1435         (JSC::WASMFunctionSyntaxChecker::buildStore):
1436
1437 2015-09-20  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1438
1439         Implement SetLocal and SetGlobal expressions in WebAssembly
1440         https://bugs.webkit.org/show_bug.cgi?id=149383
1441
1442         Reviewed by Saam Barati.
1443
1444         SetLocal and SetGlobal in WebAssembly can be both statements and
1445         expressions. We have implemented the statement version. This patch
1446         implements the expression version.
1447
1448         SetLocal and SetGlobal expressions return the assigned value.
1449         Since SetLocal and SetGlobal use only one operand, which is the assigned
1450         value, we can simply implement them by not removing the value from the
1451         top of the stack.
1452
1453         * tests/stress/wasm-globals.js:
1454         * tests/stress/wasm-locals.js:
1455         * tests/stress/wasm/globals.wasm:
1456         * tests/stress/wasm/locals.wasm:
1457         * wasm/WASMConstants.h:
1458         * wasm/WASMFunctionCompiler.h:
1459         (JSC::WASMFunctionCompiler::buildSetLocal):
1460         (JSC::WASMFunctionCompiler::buildSetGlobal):
1461         * wasm/WASMFunctionParser.cpp:
1462         (JSC::WASMFunctionParser::parseStatement):
1463         (JSC::WASMFunctionParser::parseExpressionI32):
1464         (JSC::WASMFunctionParser::parseExpressionF32):
1465         (JSC::WASMFunctionParser::parseExpressionF64):
1466         (JSC::WASMFunctionParser::parseSetLocal):
1467         (JSC::WASMFunctionParser::parseSetGlobal):
1468         (JSC::WASMFunctionParser::parseSetLocalStatement): Deleted.
1469         (JSC::WASMFunctionParser::parseSetGlobalStatement): Deleted.
1470         * wasm/WASMFunctionParser.h:
1471         * wasm/WASMFunctionSyntaxChecker.h:
1472         (JSC::WASMFunctionSyntaxChecker::buildSetLocal):
1473         (JSC::WASMFunctionSyntaxChecker::buildSetGlobal):
1474
1475 2015-09-19 Aleksandr Skachkov    <gskachkov@gmail.com>
1476
1477         [ES6] Added controlFlowProfiler test for arrow function
1478         https://bugs.webkit.org/show_bug.cgi?id=145638
1479
1480         Reviewed by Saam Barati.
1481
1482         * Source/JavaScriptCore/tests/controlFlowProfiler/arrowfunction-expression.js: added
1483
1484 2015-09-20  Youenn Fablet  <youenn.fablet@crf.canon.fr>
1485
1486         Remove XHR_TIMEOUT compilation guard
1487         https://bugs.webkit.org/show_bug.cgi?id=149260
1488
1489         Reviewed by Benjamin Poulain.
1490
1491         * Configurations/FeatureDefines.xcconfig:
1492
1493 2015-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1494
1495         [GTK] Unreviewed, should check the result of fread
1496         https://bugs.webkit.org/show_bug.cgi?id=148917
1497
1498         Suppress the build warning on GTK with GCC.
1499
1500         * jsc.cpp:
1501         (fillBufferWithContentsOfFile):
1502         (fetchModuleFromLocalFileSystem):
1503
1504 2015-09-19  Saam barati  <sbarati@apple.com>
1505
1506         VariableEnvironmentNode should inherit from ParserArenaDeletable because VariableEnvironment's must have their destructors run
1507         https://bugs.webkit.org/show_bug.cgi?id=149359
1508
1509         Reviewed by Andreas Kling.
1510
1511         VariableEnvironment must have its destructor run.
1512         Therefore, VariableEnvironmentNode should inherit from ParserArenaDeletable.
1513         Also, anything that inherits from VariableEnvironmentNode must use
1514         ParserArenaDeletable's operator new. Also, any other nodes that own
1515         a VariableEnvironment must also have their destructors run.
1516
1517         * parser/Nodes.h:
1518         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
1519
1520 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1521
1522         Remove duplicate code in the WebAssembly parser
1523         https://bugs.webkit.org/show_bug.cgi?id=149361
1524
1525         Reviewed by Saam Barati.
1526
1527         Refactor the methods for parsing GetLocal and GetGlobal in WebAssembly
1528         to remove duplicate code.
1529
1530         * wasm/WASMFunctionParser.cpp:
1531         (JSC::nameOfType):
1532         (JSC::WASMFunctionParser::parseExpressionI32):
1533         (JSC::WASMFunctionParser::parseExpressionF32):
1534         (JSC::WASMFunctionParser::parseExpressionF64):
1535         (JSC::WASMFunctionParser::parseUnaryExpressionF64):
1536         (JSC::WASMFunctionParser::parseBinaryExpressionF64):
1537         (JSC::WASMFunctionParser::parseGetLocalExpression):
1538         (JSC::WASMFunctionParser::parseGetGlobalExpression):
1539         (JSC::WASMFunctionParser::parseGetLocalExpressionI32): Deleted.
1540         (JSC::WASMFunctionParser::parseGetGlobalExpressionI32): Deleted.
1541         (JSC::WASMFunctionParser::parseGetLocalExpressionF32): Deleted.
1542         (JSC::WASMFunctionParser::parseGetGlobalExpressionF32): Deleted.
1543         (JSC::WASMFunctionParser::parseGetLocalExpressionF64): Deleted.
1544         (JSC::WASMFunctionParser::parseGetGlobalExpressionF64): Deleted.
1545         * wasm/WASMFunctionParser.h:
1546
1547 2015-09-18  Saam barati  <sbarati@apple.com>
1548
1549         Refactor common code between GetCatchHandlerFunctor and UnwindFunctor
1550         https://bugs.webkit.org/show_bug.cgi?id=149276
1551
1552         Reviewed by Mark Lam.
1553
1554         There is currently code copy-pasted between these
1555         two functors. Lets not do that. It's better to write
1556         a function, even if the function is small.
1557
1558         I also did a bit of renaming to make the intent of the
1559         unwindCallFrame function clear. The name of the function
1560         didn't really indicate what it did. It decided if it was
1561         okay to unwind further, and it also notified the debugger.
1562         I've renamed the function to notifyDebuggerOfUnwinding.
1563         And I've inlined the logic of deciding if it's okay
1564         to unwind further into UnwindFunctor itself.
1565
1566         * interpreter/Interpreter.cpp:
1567         (JSC::Interpreter::isOpcode):
1568         (JSC::getStackFrameCodeType):
1569         (JSC::Interpreter::stackTraceAsString):
1570         (JSC::findExceptionHandler):
1571         (JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
1572         (JSC::GetCatchHandlerFunctor::operator()):
1573         (JSC::notifyDebuggerOfUnwinding):
1574         (JSC::UnwindFunctor::UnwindFunctor):
1575         (JSC::UnwindFunctor::operator()):
1576         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
1577         (JSC::unwindCallFrame): Deleted.
1578
1579 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1580
1581         Implement the arithmetic instructions for doubles in WebAssembly
1582         https://bugs.webkit.org/show_bug.cgi?id=148945
1583
1584         Reviewed by Geoffrey Garen.
1585
1586         This patch implements the arithmetic instructions for doubles (float64)
1587         in WebAssembly.
1588
1589         * tests/stress/wasm-arithmetic-float64.js:
1590         * tests/stress/wasm/arithmetic-float64.wasm:
1591         * wasm/WASMFunctionCompiler.h:
1592         (JSC::WASMFunctionCompiler::buildUnaryF64):
1593         (JSC::WASMFunctionCompiler::buildBinaryF64):
1594         (JSC::WASMFunctionCompiler::callOperation):
1595         * wasm/WASMFunctionParser.cpp:
1596         (JSC::WASMFunctionParser::parseExpressionF64):
1597         (JSC::WASMFunctionParser::parseUnaryExpressionF64):
1598         (JSC::WASMFunctionParser::parseBinaryExpressionF64):
1599         * wasm/WASMFunctionParser.h:
1600         * wasm/WASMFunctionSyntaxChecker.h:
1601         (JSC::WASMFunctionSyntaxChecker::buildUnaryF64):
1602         (JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
1603         (JSC::WASMFunctionSyntaxChecker::buildBinaryF64):
1604
1605 2015-09-18  Basile Clement  <basile_clement@apple.com>
1606
1607         [ES6] Tail call fast path should efficiently reuse the frame's stack space
1608         https://bugs.webkit.org/show_bug.cgi?id=148662
1609
1610         Reviewed by Geoffrey Garen.
1611
1612         This introduces a new class (CallFrameShuffler) that is responsible for
1613         efficiently building the new frames when performing a tail call. In
1614         order for Repatch to know about the position of arguments on the
1615         stack/registers (e.g. for polymorphic call inline caches), we store a
1616         CallFrameShuffleData in the CallLinkInfo. Otherwise, the JIT and DFG
1617         compiler are now using CallFrameShuffler instead of
1618         CCallHelpers::prepareForTailCallSlow() to build the frame for a tail
1619         call.
1620
1621         When taking a slow path, we still build the frame as if doing a regular
1622         call, because we could throw an exception and need the caller's frame
1623         at that point. This means that for virtual calls, we don't benefit from
1624         the efficient frame move for now.
1625
1626         * CMakeLists.txt:
1627         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1628         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1629         * JavaScriptCore.xcodeproj/project.pbxproj:
1630         * assembler/ARMv7Assembler.h:
1631         (JSC::ARMv7Assembler::firstRegister):
1632         (JSC::ARMv7Assembler::lastRegister):
1633         (JSC::ARMv7Assembler::firstFPRegister):
1634         (JSC::ARMv7Assembler::lastFPRegister):
1635         * assembler/AbortReason.h:
1636         * bytecode/CallLinkInfo.h:
1637         (JSC::CallLinkInfo::setFrameShuffleData):
1638         (JSC::CallLinkInfo::frameShuffleData):
1639         * bytecode/ValueRecovery.h:
1640         (JSC::ValueRecovery::inRegister):
1641         * dfg/DFGGenerationInfo.h:
1642         (JSC::DFG::GenerationInfo::recovery):
1643         * jit/CachedRecovery.cpp: Added.
1644         (JSC::CachedRecovery::loadsIntoFPR):
1645         (JSC::CachedRecovery::loadsIntoGPR):
1646         * jit/CachedRecovery.h: Added.
1647         (JSC::CachedRecovery::CachedRecovery):
1648         (JSC::CachedRecovery::targets):
1649         (JSC::CachedRecovery::addTarget):
1650         (JSC::CachedRecovery::removeTarget):
1651         (JSC::CachedRecovery::clearTargets):
1652         (JSC::CachedRecovery::setWantedJSValueRegs):
1653         (JSC::CachedRecovery::setWantedFPR):
1654         (JSC::CachedRecovery::boxingRequiresGPR):
1655         (JSC::CachedRecovery::boxingRequiresFPR):
1656         (JSC::CachedRecovery::recovery):
1657         (JSC::CachedRecovery::setRecovery):
1658         (JSC::CachedRecovery::wantedJSValueRegs):
1659         (JSC::CachedRecovery::wantedFPR):
1660         * jit/CallFrameShuffleData.cpp: Added.
1661         (JSC::CallFrameShuffleData::setupCalleeSaveRegisters):
1662         * jit/CallFrameShuffleData.h: Added.
1663         * jit/CallFrameShuffler.cpp: Added.
1664         (JSC::CallFrameShuffler::CallFrameShuffler):
1665         (JSC::CallFrameShuffler::dump):
1666         (JSC::CallFrameShuffler::getCachedRecovery):
1667         (JSC::CallFrameShuffler::setCachedRecovery):
1668         (JSC::CallFrameShuffler::spill):
1669         (JSC::CallFrameShuffler::emitDeltaCheck):
1670         (JSC::CallFrameShuffler::prepareForSlowPath):
1671         (JSC::CallFrameShuffler::prepareForTailCall):
1672         (JSC::CallFrameShuffler::tryWrites):
1673         (JSC::CallFrameShuffler::performSafeWrites):
1674         (JSC::CallFrameShuffler::prepareAny):
1675         * jit/CallFrameShuffler.h: Added.
1676         (JSC::CallFrameShuffler::lockGPR):
1677         (JSC::CallFrameShuffler::acquireGPR):
1678         (JSC::CallFrameShuffler::releaseGPR):
1679         (JSC::CallFrameShuffler::snapshot):
1680         (JSC::CallFrameShuffler::setCalleeJSValueRegs):
1681         (JSC::CallFrameShuffler::assumeCalleeIsCell):
1682         (JSC::CallFrameShuffler::canBox):
1683         (JSC::CallFrameShuffler::ensureBox):
1684         (JSC::CallFrameShuffler::ensureLoad):
1685         (JSC::CallFrameShuffler::canLoadAndBox):
1686         (JSC::CallFrameShuffler::updateRecovery):
1687         (JSC::CallFrameShuffler::clearCachedRecovery):
1688         (JSC::CallFrameShuffler::addCachedRecovery):
1689         (JSC::CallFrameShuffler::numLocals):
1690         (JSC::CallFrameShuffler::getOld):
1691         (JSC::CallFrameShuffler::setOld):
1692         (JSC::CallFrameShuffler::firstOld):
1693         (JSC::CallFrameShuffler::lastOld):
1694         (JSC::CallFrameShuffler::isValidOld):
1695         (JSC::CallFrameShuffler::argCount):
1696         (JSC::CallFrameShuffler::getNew):
1697         (JSC::CallFrameShuffler::setNew):
1698         (JSC::CallFrameShuffler::addNew):
1699         (JSC::CallFrameShuffler::firstNew):
1700         (JSC::CallFrameShuffler::lastNew):
1701         (JSC::CallFrameShuffler::isValidNew):
1702         (JSC::CallFrameShuffler::newAsOld):
1703         (JSC::CallFrameShuffler::getFreeRegister):
1704         (JSC::CallFrameShuffler::getFreeGPR):
1705         (JSC::CallFrameShuffler::getFreeFPR):
1706         (JSC::CallFrameShuffler::hasFreeRegister):
1707         (JSC::CallFrameShuffler::ensureRegister):
1708         (JSC::CallFrameShuffler::ensureGPR):
1709         (JSC::CallFrameShuffler::ensureFPR):
1710         (JSC::CallFrameShuffler::addressForOld):
1711         (JSC::CallFrameShuffler::isUndecided):
1712         (JSC::CallFrameShuffler::isSlowPath):
1713         (JSC::CallFrameShuffler::addressForNew):
1714         (JSC::CallFrameShuffler::dangerFrontier):
1715         (JSC::CallFrameShuffler::isDangerNew):
1716         (JSC::CallFrameShuffler::updateDangerFrontier):
1717         (JSC::CallFrameShuffler::hasOnlySafeWrites):
1718         * jit/CallFrameShuffler32_64.cpp: Added.
1719         (JSC::CallFrameShuffler::emitStore):
1720         (JSC::CallFrameShuffler::emitBox):
1721         (JSC::CallFrameShuffler::emitLoad):
1722         (JSC::CallFrameShuffler::canLoad):
1723         (JSC::CallFrameShuffler::emitDisplace):
1724         * jit/CallFrameShuffler64.cpp: Added.
1725         (JSC::CallFrameShuffler::emitStore):
1726         (JSC::CallFrameShuffler::emitBox):
1727         (JSC::CallFrameShuffler::emitLoad):
1728         (JSC::CallFrameShuffler::canLoad):
1729         (JSC::CallFrameShuffler::emitDisplace):
1730         * jit/JITCall.cpp:
1731         (JSC::JIT::compileOpCall):
1732         (JSC::JIT::compileOpCallSlowCase):
1733         * jit/RegisterMap.cpp:
1734         (JSC::RegisterMap::RegisterMap):
1735         (JSC::GPRMap::GPRMap):
1736         (JSC::FPRMap::FPRMap):
1737         * jit/Repatch.cpp:
1738         (JSC::linkPolymorphicCall):
1739
1740 2015-09-18  Saam barati  <sbarati@apple.com>
1741
1742         Implement try/catch in the DFG.
1743         https://bugs.webkit.org/show_bug.cgi?id=147374
1744
1745         Reviewed by Filip Pizlo.
1746
1747         This patch implements try/catch inside the DFG JIT.
1748         It also prevents tier up to the FTL for any functions
1749         that have an op_catch in them that are DFG compiled.
1750
1751         This patch accomplishes implementing try/catch inside
1752         the DFG by OSR exiting to op_catch when an exception is thrown.
1753         We can OSR exit from an exception inside the DFG in two ways:
1754         1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
1755         2) We have an exception when returing from a callOperation
1756
1757         In the case of (1), we get to the OSR exit from genericUnwind because
1758         the exception was thrown in a child call frame. This means these
1759         OSR exits must act as defacto op_catches (even though we will still OSR
1760         exit to a baseline op_catch). That means they must restore the stack pointer
1761         and call frame.
1762
1763         In the case of (2), we can skip genericUnwind because we know the exception 
1764         check will take us to a particular OSR exit. Instead, we link these
1765         exception checks as jumps to a particular OSR exit.
1766
1767         Both types of OSR exits will exit into op_catch inside the baseline JIT.
1768         Because they exit to op_catch, these OSR exits must set callFrameForCatch
1769         to the proper call frame pointer.
1770
1771         We "handle" all exceptions inside the machine frame of the DFG code
1772         block. This means the machine code block is responsible for "catching"
1773         exceptions of any inlined frames' try/catch. OSR exit will then exit to 
1774         the proper baseline CodeBlock after reifying the inlined frames
1775         (DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to). 
1776         Also, genericUnwind will never consult an inlined call frame's CodeBlock to 
1777         see if they can catch the exception because they can't. We always unwind to the 
1778         next machine code block frame. The DFG CodeBlock changes how the exception 
1779         handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks. 
1780
1781         So, when consulting call sites that throw, we keep track of the CallSiteIndex,
1782         and the HandlerInfo for the corresponding baseline exception handler for
1783         that particular CallSiteIndex (if an exception at that call site will be caught). 
1784         Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
1785         inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
1786         (The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
1787         at from genericUnwind).
1788
1789         Also, each OSR exit will know if it acting as an exception handler, and
1790         whether or not it will be arrived at from genericUnwind. When we know we 
1791         will arrive at an OSR exit from genericUnwind, we set the corresponding 
1792         HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.
1793
1794         This patch also introduces a new Phase inside the DFG that ensures
1795         that DFG CodeBlocks that handle exceptions take the necessary
1796         steps to keep live variables at "op_catch" live according the
1797         OSR exit value recovery machinery. We accomplish this by flushing
1798         all live op_catch variables to the stack when inside a "try" block.
1799
1800         * CMakeLists.txt:
1801         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1802         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1803         * JavaScriptCore.xcodeproj/project.pbxproj:
1804         * bytecode/CodeBlock.cpp:
1805         (JSC::CodeBlock::handlerForBytecodeOffset):
1806         (JSC::CodeBlock::handlerForIndex):
1807         * bytecode/CodeBlock.h:
1808         (JSC::CodeBlock::clearExceptionHandlers):
1809         (JSC::CodeBlock::appendExceptionHandler):
1810         * bytecode/PreciseJumpTargets.cpp:
1811         (JSC::computePreciseJumpTargets):
1812         * dfg/DFGByteCodeParser.cpp:
1813         (JSC::DFG::ByteCodeParser::getLocal):
1814         (JSC::DFG::ByteCodeParser::setLocal):
1815         (JSC::DFG::ByteCodeParser::parseBlock):
1816         * dfg/DFGCapabilities.cpp:
1817         (JSC::DFG::capabilityLevel):
1818         * dfg/DFGCommonData.cpp:
1819         (JSC::DFG::CommonData::addCodeOrigin):
1820         (JSC::DFG::CommonData::lastCallSite):
1821         (JSC::DFG::CommonData::shrinkToFit):
1822         * dfg/DFGCommonData.h:
1823         * dfg/DFGGraph.h:
1824         * dfg/DFGJITCompiler.cpp:
1825         (JSC::DFG::JITCompiler::linkOSRExits):
1826         (JSC::DFG::JITCompiler::link):
1827         (JSC::DFG::JITCompiler::compile):
1828         (JSC::DFG::JITCompiler::noticeOSREntry):
1829         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
1830         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
1831         (JSC::DFG::JITCompiler::exceptionCheck):
1832         (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
1833         * dfg/DFGJITCompiler.h:
1834         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
1835         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
1836         (JSC::DFG::JITCompiler::appendCall):
1837         (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
1838         (JSC::DFG::JITCompiler::blockHeads):
1839         (JSC::DFG::JITCompiler::exceptionCheck): Deleted.
1840         * dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
1841         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
1842         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
1843         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
1844         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
1845         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
1846         (JSC::DFG::performLiveCatchVariablePreservationPhase):
1847         * dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
1848         * dfg/DFGOSRExit.cpp:
1849         (JSC::DFG::OSRExit::OSRExit):
1850         (JSC::DFG::OSRExit::setPatchableCodeOffset):
1851         * dfg/DFGOSRExit.h:
1852         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
1853         * dfg/DFGOSRExitCompiler.cpp:
1854         * dfg/DFGOSRExitCompiler32_64.cpp:
1855         (JSC::DFG::OSRExitCompiler::compileExit):
1856         * dfg/DFGOSRExitCompiler64.cpp:
1857         (JSC::DFG::OSRExitCompiler::compileExit):
1858         * dfg/DFGOSRExitCompilerCommon.cpp:
1859         (JSC::DFG::osrWriteBarrier):
1860         (JSC::DFG::adjustAndJumpToTarget):
1861         * dfg/DFGOSRExitCompilerCommon.h:
1862         * dfg/DFGPlan.cpp:
1863         (JSC::DFG::Plan::compileInThreadImpl):
1864         * dfg/DFGSlowPathGenerator.h:
1865         (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
1866         (JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
1867         (JSC::DFG::SlowPathGenerator::generate):
1868         * dfg/DFGSpeculativeJIT.h:
1869         * dfg/DFGSpeculativeJIT32_64.cpp:
1870         (JSC::DFG::SpeculativeJIT::cachedGetById):
1871         (JSC::DFG::SpeculativeJIT::cachedPutById):
1872         (JSC::DFG::SpeculativeJIT::emitCall):
1873         * dfg/DFGSpeculativeJIT64.cpp:
1874         (JSC::DFG::SpeculativeJIT::cachedGetById):
1875         (JSC::DFG::SpeculativeJIT::cachedPutById):
1876         (JSC::DFG::SpeculativeJIT::emitCall):
1877         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1878         (JSC::DFG::TierUpCheckInjectionPhase::run):
1879         * ftl/FTLOSRExitCompiler.cpp:
1880         (JSC::FTL::compileStub):
1881         * interpreter/Interpreter.cpp:
1882         (JSC::GetCatchHandlerFunctor::operator()):
1883         (JSC::UnwindFunctor::operator()):
1884         * interpreter/StackVisitor.cpp:
1885         (JSC::StackVisitor::gotoNextFrame):
1886         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
1887         (JSC::StackVisitor::readFrame):
1888         * interpreter/StackVisitor.h:
1889         (JSC::StackVisitor::operator*):
1890         (JSC::StackVisitor::operator->):
1891         * jit/AssemblyHelpers.cpp:
1892         (JSC::AssemblyHelpers::emitExceptionCheck):
1893         (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
1894         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
1895         * jit/AssemblyHelpers.h:
1896         (JSC::AssemblyHelpers::emitCount):
1897         * jit/JITExceptions.cpp:
1898         (JSC::genericUnwind):
1899         * jit/JITOpcodes.cpp:
1900         (JSC::JIT::emit_op_catch):
1901         * jit/JITOpcodes32_64.cpp:
1902         (JSC::JIT::emit_op_catch):
1903         * llint/LowLevelInterpreter32_64.asm:
1904         * llint/LowLevelInterpreter64.asm:
1905         * runtime/VM.cpp:
1906         (JSC::VM::VM):
1907         * runtime/VM.h:
1908         (JSC::VM::clearException):
1909         (JSC::VM::clearLastException):
1910         (JSC::VM::addressOfCallFrameForCatch):
1911         (JSC::VM::exception):
1912         (JSC::VM::addressOfException):
1913         * tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
1914         (f):
1915         (bar):
1916         (Foo):
1917         * tests/stress/es6-for-of-loop-exception.js: Added.
1918         (assert):
1919         (shouldThrowInvalidConstAssignment):
1920         (baz):
1921         (foo):
1922         * tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
1923         (assert):
1924         (o.valueOf):
1925         (o.toString):
1926         (read):
1927         (bar):
1928         (foo):
1929         * tests/stress/exception-dfg-not-strict-equal.js: Added.
1930         (foo):
1931         (o.valueOf):
1932         (o.toString):
1933         (assert):
1934         (shouldDoSomethingInFinally):
1935         (catch):
1936         * tests/stress/exception-dfg-operation-read-value.js: Added.
1937         (assert):
1938         (o.valueOf):
1939         (o.toString):
1940         (read):
1941         (foo):
1942         * tests/stress/exception-dfg-throw-from-catch-block.js: Added.
1943         (assert):
1944         (baz):
1945         (bar):
1946         (foo):
1947
1948 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1949
1950         Implement linear memory instructions in WebAssembly
1951         https://bugs.webkit.org/show_bug.cgi?id=149326
1952
1953         Reviewed by Geoffrey Garen.
1954
1955         This patch implements linear memory instructions in WebAssembly.[1] To
1956         use the linear memory, an ArrayBuffer must be passed to loadWebAssembly().
1957
1958         Notes:
1959         - We limit the ArrayBuffer's byte length to 2^31 - 1. This enables us to
1960           use only one comparison (unsigned greater than) to check for
1961           out-of-bounds access.
1962         - There is no consensus yet on what should happen when an out-of-bounds
1963           access occurs.[2] For now, we throw an error when that happens.
1964         - In asm.js, a heap access looks like this: int32Array[i >> 2]. Note
1965           that ">> 2" is part of the syntax and is required. pack-asmjs will
1966           produce bytecodes that look something like "LoadI32, i" (not
1967           "LoadI32, ShiftRightI32, i, 2"). The requirement of the shift operator
1968           prevents unaligned accesses in asm.js. (There is a proposal to support
1969           unaligned accesses in the future version of asm.js using DataView.[3])
1970           The WebAssembly spec allows unaligned accesses.[4] But since we use
1971           asm.js for testing, we follow asm.js's behaviors for now.
1972
1973         [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#linear-memory
1974         [2]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#out-of-bounds
1975         [3]: https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Possible_asm.js_extensions_that_don.27t_require_new_JS_features
1976         [4]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#alignment
1977
1978         * jit/JITOperations.cpp:
1979         * jit/JITOperations.h:
1980         * jsc.cpp:
1981         (GlobalObject::finishCreation):
1982         (functionLoadWebAssembly):
1983         * tests/stress/wasm-linear-memory.js: Added.
1984         (shouldBe):
1985         (shouldThrow):
1986         * tests/stress/wasm/linear-memory.wasm: Added.
1987         * wasm/JSWASMModule.cpp:
1988         (JSC::JSWASMModule::JSWASMModule):
1989         (JSC::JSWASMModule::visitChildren):
1990         * wasm/JSWASMModule.h:
1991         (JSC::JSWASMModule::create):
1992         (JSC::JSWASMModule::arrayBuffer):
1993         (JSC::JSWASMModule::JSWASMModule): Deleted.
1994         * wasm/WASMConstants.h:
1995         * wasm/WASMFunctionCompiler.h:
1996         (JSC::sizeOfMemoryType):
1997         (JSC::WASMFunctionCompiler::MemoryAddress::MemoryAddress):
1998         (JSC::WASMFunctionCompiler::endFunction):
1999         (JSC::WASMFunctionCompiler::buildLoad):
2000         (JSC::WASMFunctionCompiler::buildStore):
2001         * wasm/WASMFunctionParser.cpp:
2002         (JSC::WASMFunctionParser::parseStatement):
2003         (JSC::WASMFunctionParser::parseExpressionI32):
2004         (JSC::WASMFunctionParser::parseExpressionF32):
2005         (JSC::WASMFunctionParser::parseExpressionF64):
2006         (JSC::WASMFunctionParser::parseMemoryAddress):
2007         (JSC::WASMFunctionParser::parseLoad):
2008         (JSC::WASMFunctionParser::parseStore):
2009         * wasm/WASMFunctionParser.h:
2010         * wasm/WASMFunctionSyntaxChecker.h:
2011         (JSC::WASMFunctionSyntaxChecker::MemoryAddress::MemoryAddress):
2012         (JSC::WASMFunctionSyntaxChecker::buildLoad):
2013         (JSC::WASMFunctionSyntaxChecker::buildStore):
2014         * wasm/WASMModuleParser.cpp:
2015         (JSC::WASMModuleParser::WASMModuleParser):
2016         (JSC::WASMModuleParser::parseModule):
2017         (JSC::parseWebAssembly):
2018         (JSC::WASMModuleParser::parse): Deleted.
2019         * wasm/WASMModuleParser.h:
2020
2021 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2022
2023         Implement type conversion instructions in WebAssembly
2024         https://bugs.webkit.org/show_bug.cgi?id=149340
2025
2026         Reviewed by Mark Lam.
2027
2028         This patch implements some type conversion instructions in WebAssembly.
2029         The WebAssembly spec has a lot more type conversion instructions than
2030         what are available in asm.js.[1] We only implement the ones that are in
2031         asm.js for now because we can only test those.
2032
2033         [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md
2034
2035         * tests/stress/wasm-type-conversion.js:
2036         * tests/stress/wasm/type-conversion.wasm:
2037         * wasm/WASMConstants.h:
2038         * wasm/WASMFunctionCompiler.h:
2039         (JSC::operationConvertUnsignedInt32ToDouble):
2040         (JSC::WASMFunctionCompiler::buildConvertType):
2041         (JSC::WASMFunctionCompiler::callOperation):
2042         * wasm/WASMFunctionParser.cpp:
2043         (JSC::WASMFunctionParser::parseExpressionI32):
2044         (JSC::WASMFunctionParser::parseExpressionF32):
2045         (JSC::WASMFunctionParser::parseExpressionF64):
2046         (JSC::WASMFunctionParser::parseConvertType):
2047         * wasm/WASMFunctionParser.h:
2048         * wasm/WASMFunctionSyntaxChecker.h:
2049         (JSC::WASMFunctionSyntaxChecker::buildConvertType):
2050
2051 2015-09-18  Alex Christensen  <achristensen@webkit.org>
2052
2053         Fix tests on Windows after switching to CMake.
2054         https://bugs.webkit.org/show_bug.cgi?id=149339
2055
2056         Reviewed by Brent Fulgham.
2057
2058         * shell/PlatformWin.cmake:
2059         Build testapi and testRegExp (which doesn't seem to be used any more).
2060
2061 2015-09-17  Brian Burg  <bburg@apple.com>
2062
2063         ASSERT(!m_frontendRouter->hasLocalFrontend()) when running Web Inspector tests
2064         https://bugs.webkit.org/show_bug.cgi?id=149006
2065
2066         Reviewed by Joseph Pecoraro.
2067
2068         Prior to disconnecting, we need to know how many frontends remain connected.
2069
2070         * inspector/InspectorFrontendRouter.h: Add frontendCount().
2071
2072 2015-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2073
2074         Explicitly specify builtin JS files dependency
2075         https://bugs.webkit.org/show_bug.cgi?id=149323
2076
2077         Reviewed by Alex Christensen.
2078
2079         JSCBuiltins.{h,cpp} in CMakeLists.txt and DerivedSources.make just depend on the builtins directory.
2080         As a result, even if we modify builtins/*.js code, regenerating JSCBuiltins.{h,cpp} does not occur.
2081         As the same to the cpp sources, let's list up the JS files explicitly.
2082
2083         * CMakeLists.txt:
2084         * DerivedSources.make:
2085
2086 2015-09-18  Michael Saboff  <msaboff@apple.com>
2087
2088         Remove register preservation and restoration stub code
2089         https://bugs.webkit.org/show_bug.cgi?id=149335
2090
2091         Reviewed by Mark Lam.
2092
2093         Delete the register preservation and restoration thunks and related plumbing.
2094
2095         Much of this change is removing the unneeded RegisterPreservationMode parameter
2096         from various functions.
2097
2098         * CMakeLists.txt:
2099         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2100         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2101         * JavaScriptCore.xcodeproj/project.pbxproj:
2102         * bytecode/CallLinkInfo.h:
2103         (JSC::CallLinkInfo::isVarargsCallType):
2104         (JSC::CallLinkInfo::CallLinkInfo):
2105         (JSC::CallLinkInfo::isVarargs):
2106         (JSC::CallLinkInfo::isLinked):
2107         (JSC::CallLinkInfo::setUpCallFromFTL):
2108         (JSC::CallLinkInfo::registerPreservationMode): Deleted.
2109         * ftl/FTLJITCode.cpp:
2110         (JSC::FTL::JITCode::initializeAddressForCall):
2111         (JSC::FTL::JITCode::addressForCall):
2112         * ftl/FTLJITCode.h:
2113         * ftl/FTLOSREntry.cpp:
2114         (JSC::FTL::prepareOSREntry):
2115         * ftl/FTLOSRExitCompiler.cpp:
2116         (JSC::FTL::compileStub):
2117         * jit/JITCode.cpp:
2118         (JSC::JITCode::execute):
2119         (JSC::DirectJITCode::initializeCodeRef):
2120         (JSC::DirectJITCode::addressForCall):
2121         (JSC::NativeJITCode::initializeCodeRef):
2122         (JSC::NativeJITCode::addressForCall):
2123         (JSC::DirectJITCode::ensureWrappers): Deleted.
2124         * jit/JITCode.h:
2125         (JSC::JITCode::jitTypeFor):
2126         (JSC::JITCode::executableAddress):
2127         * jit/JITOperations.cpp:
2128         * jit/RegisterPreservationWrapperGenerator.cpp: Removed.
2129         * jit/RegisterPreservationWrapperGenerator.h: Removed.
2130         * jit/Repatch.cpp:
2131         (JSC::linkPolymorphicCall):
2132         * jit/ThunkGenerators.cpp:
2133         (JSC::virtualThunkFor):
2134         * jit/ThunkGenerators.h:
2135         * llint/LLIntSlowPaths.cpp:
2136         (JSC::LLInt::entryOSR):
2137         (JSC::LLInt::setUpCall):
2138         * runtime/Executable.cpp:
2139         (JSC::ExecutableBase::clearCode):
2140         (JSC::ScriptExecutable::installCode):
2141         (JSC::WebAssemblyExecutable::prepareForExecution):
2142         * runtime/Executable.h:
2143         (JSC::ExecutableBase::generatedJITCodeFor):
2144         (JSC::ExecutableBase::entrypointFor):
2145         (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
2146         * runtime/RegisterPreservationMode.h: Removed.
2147
2148 2015-09-17  Joseph Pecoraro  <pecoraro@apple.com>
2149
2150         Web Inspector: Remove unused canClearBrowserCookies / canClearBrowserCache protocol methods
2151         https://bugs.webkit.org/show_bug.cgi?id=149307
2152
2153         Reviewed by Brian Burg.
2154
2155         * inspector/protocol/Network.json:
2156         Remove unused protocol methods.
2157
2158 2015-09-17  Commit Queue  <commit-queue@webkit.org>
2159
2160         Unreviewed, rolling out r189938, r189952, and r189956.
2161         https://bugs.webkit.org/show_bug.cgi?id=149329
2162
2163         Broke Web Workers (Requested by ap on #webkit).
2164
2165         Reverted changesets:
2166
2167         "Implement try/catch in the DFG."
2168         https://bugs.webkit.org/show_bug.cgi?id=147374
2169         http://trac.webkit.org/changeset/189938
2170
2171         "CLoop build fix after r189938."
2172         http://trac.webkit.org/changeset/189952
2173
2174         "add a regress test for richards with try/catch."
2175         https://bugs.webkit.org/show_bug.cgi?id=149301
2176         http://trac.webkit.org/changeset/189956
2177
2178 2015-09-17  Ryosuke Niwa  <rniwa@webkit.org>
2179
2180         CLoop build fix after r189938.
2181
2182         * interpreter/StackVisitor.cpp:
2183         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
2184
2185 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2186
2187         Convert return values from JavaScript functions to the expected types in WebAssembly
2188         https://bugs.webkit.org/show_bug.cgi?id=149200
2189
2190         Reviewed by Mark Lam.
2191
2192         When a WebAssembly function calls a JavaScript function, there is no
2193         guarantee that the JavaScript function will always return values of the
2194         type we expect. This patch converts the return values to the expected
2195         types.
2196
2197         (The reverse is also true: When a WebAssembly function is called from a
2198         JavaScript function, there is no guarantee that the arguments to the
2199         WebAssembly function will always be of the types we expect. We have
2200         fixed this in Bug 149033.)
2201
2202         We don't need to type check the return values if the callee is a
2203         WebAssembly function. We don't need to type check the arguments if the
2204         caller is a WebAssembly function. This optimization will be
2205         implemented in the future. See https://bugs.webkit.org/show_bug.cgi?id=149310
2206
2207         * tests/stress/wasm-type-conversion.js:
2208         * tests/stress/wasm/type-conversion.wasm:
2209         * wasm/WASMFunctionCompiler.h:
2210         (JSC::WASMFunctionCompiler::startFunction):
2211         (JSC::WASMFunctionCompiler::buildReturn):
2212         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
2213         (JSC::WASMFunctionCompiler::callAndUnboxResult):
2214         (JSC::WASMFunctionCompiler::convertValueToInt32):
2215         (JSC::WASMFunctionCompiler::convertValueToDouble):
2216         (JSC::WASMFunctionCompiler::convertDoubleToValue):
2217         (JSC::WASMFunctionCompiler::loadValueAndConvertToInt32): Deleted.
2218         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble): Deleted.
2219         * wasm/WASMFunctionParser.cpp:
2220         (JSC::WASMFunctionParser::parseExpressionI32):
2221         (JSC::WASMFunctionParser::parseExpressionF32):
2222         (JSC::WASMFunctionParser::parseExpressionF64):
2223         (JSC::WASMFunctionParser::parseCallInternalExpressionI32): Deleted.
2224         * wasm/WASMFunctionParser.h:
2225
2226 2015-09-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2227
2228         [ES6] Add more fine-grained APIs and additional hooks to control module loader from WebCore
2229         https://bugs.webkit.org/show_bug.cgi?id=149129
2230
2231         Reviewed by Saam Barati.
2232
2233         No behavior change.
2234
2235         Module tag `<script type="module>` will be executed asynchronously.
2236         But we would like to fetch the resources before when the postTask-ed task is performed.
2237         So instead of 1 API that fetch, instantiate and execute the module,
2238         we need 2 fine-grained APIs.
2239
2240         1. Fetch and initialize a module, but not execute it yet.
2241         2. Link and execute a module specified by the key (this will be invoked asynchronously).
2242
2243         And to instrument the script execution (like reporting the execution time of the module to
2244         the inspector), we need a hook to inject code around an execution of a module body.
2245
2246         * builtins/ModuleLoaderObject.js:
2247         (moduleEvaluation):
2248         (loadAndEvaluateModule):
2249         (loadModule):
2250         (linkAndEvaluateModule):
2251         * jsc.cpp:
2252         (functionLoadModule):
2253         (runWithScripts):
2254         * runtime/Completion.cpp:
2255         (JSC::identifierToJSValue):
2256         (JSC::createSymbolForEntryPointModule):
2257         (JSC::rejectPromise):
2258         (JSC::loadAndEvaluateModule):
2259         (JSC::loadModule):
2260         (JSC::linkAndEvaluateModule):
2261         (JSC::evaluateModule): Deleted.
2262         * runtime/Completion.h:
2263         * runtime/JSGlobalObject.cpp:
2264         * runtime/JSGlobalObject.h:
2265         * runtime/JSModuleRecord.cpp:
2266         (JSC::JSModuleRecord::evaluate):
2267         (JSC::JSModuleRecord::execute): Deleted.
2268         * runtime/JSModuleRecord.h:
2269         * runtime/ModuleLoaderObject.cpp:
2270         (JSC::ModuleLoaderObject::loadAndEvaluateModule):
2271         (JSC::ModuleLoaderObject::linkAndEvaluateModule):
2272         (JSC::ModuleLoaderObject::evaluate):
2273         (JSC::moduleLoaderObjectEvaluate):
2274         * runtime/ModuleLoaderObject.h:
2275
2276 2015-09-17  Saam barati  <sbarati@apple.com>
2277
2278         Implement try/catch in the DFG.
2279         https://bugs.webkit.org/show_bug.cgi?id=147374
2280
2281         Reviewed by Filip Pizlo.
2282
2283         This patch implements try/catch inside the DFG JIT.
2284         It also prevents tier up to the FTL for any functions
2285         that have an op_catch in them that are DFG compiled.
2286
2287         This patch accomplishes implementing try/catch inside
2288         the DFG by OSR exiting to op_catch when an exception is thrown.
2289         We can OSR exit from an exception inside the DFG in two ways:
2290         1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
2291         2) We have an exception when returing from a callOperation
2292
2293         In the case of (1), we get to the OSR exit from genericUnwind because
2294         the exception was thrown in a child call frame. This means these
2295         OSR exits must act as defacto op_catches (even though we will still OSR
2296         exit to a baseline op_catch). That means they must restore the stack pointer
2297         and call frame.
2298
2299         In the case of (2), we can skip genericUnwind because we know the exception 
2300         check will take us to a particular OSR exit. Instead, we link these
2301         exception checks as jumps to a particular OSR exit.
2302
2303         Both types of OSR exits will exit into op_catch inside the baseline JIT.
2304         Because they exit to op_catch, these OSR exits must set callFrameForCatch
2305         to the proper call frame pointer.
2306
2307         We "handle" all exceptions inside the machine frame of the DFG code
2308         block. This means the machine code block is responsible for "catching"
2309         exceptions of any inlined frames' try/catch. OSR exit will then exit to 
2310         the proper baseline CodeBlock after reifying the inlined frames
2311         (DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to). 
2312         Also, genericUnwind will never consult an inlined call frame's CodeBlock to 
2313         see if they can catch the exception because they can't. We always unwind to the 
2314         next machine code block frame. The DFG CodeBlock changes how the exception 
2315         handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks. 
2316
2317         So, when consulting call sites that throw, we keep track of the CallSiteIndex,
2318         and the HandlerInfo for the corresponding baseline exception handler for
2319         that particular CallSiteIndex (if an exception at that call site will be caught). 
2320         Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
2321         inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
2322         (The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
2323         at from genericUnwind).
2324
2325         Also, each OSR exit will know if it acting as an exception handler, and
2326         whether or not it will be arrived at from genericUnwind. When we know we 
2327         will arrive at an OSR exit from genericUnwind, we set the corresponding 
2328         HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.
2329
2330         This patch also introduces a new Phase inside the DFG that ensures
2331         that DFG CodeBlocks that handle exceptions take the necessary
2332         steps to keep live variables at "op_catch" live according the
2333         OSR exit value recovery machinery. We accomplish this by flushing
2334         all live op_catch variables to the stack when inside a "try" block.
2335
2336         * CMakeLists.txt:
2337         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2338         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2339         * JavaScriptCore.xcodeproj/project.pbxproj:
2340         * bytecode/CodeBlock.cpp:
2341         (JSC::CodeBlock::handlerForBytecodeOffset):
2342         (JSC::CodeBlock::handlerForIndex):
2343         * bytecode/CodeBlock.h:
2344         (JSC::CodeBlock::clearExceptionHandlers):
2345         (JSC::CodeBlock::appendExceptionHandler):
2346         * bytecode/PreciseJumpTargets.cpp:
2347         (JSC::computePreciseJumpTargets):
2348         * dfg/DFGByteCodeParser.cpp:
2349         (JSC::DFG::ByteCodeParser::getLocal):
2350         (JSC::DFG::ByteCodeParser::setLocal):
2351         (JSC::DFG::ByteCodeParser::parseBlock):
2352         * dfg/DFGCapabilities.cpp:
2353         (JSC::DFG::capabilityLevel):
2354         * dfg/DFGCommonData.cpp:
2355         (JSC::DFG::CommonData::addCodeOrigin):
2356         (JSC::DFG::CommonData::lastCallSite):
2357         (JSC::DFG::CommonData::shrinkToFit):
2358         * dfg/DFGCommonData.h:
2359         * dfg/DFGGraph.h:
2360         * dfg/DFGJITCompiler.cpp:
2361         (JSC::DFG::JITCompiler::linkOSRExits):
2362         (JSC::DFG::JITCompiler::link):
2363         (JSC::DFG::JITCompiler::compile):
2364         (JSC::DFG::JITCompiler::noticeOSREntry):
2365         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
2366         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
2367         (JSC::DFG::JITCompiler::exceptionCheck):
2368         (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
2369         * dfg/DFGJITCompiler.h:
2370         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
2371         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
2372         (JSC::DFG::JITCompiler::appendCall):
2373         (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
2374         (JSC::DFG::JITCompiler::blockHeads):
2375         (JSC::DFG::JITCompiler::exceptionCheck): Deleted.
2376         * dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
2377         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
2378         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
2379         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
2380         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
2381         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
2382         (JSC::DFG::performLiveCatchVariablePreservationPhase):
2383         * dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
2384         * dfg/DFGOSRExit.cpp:
2385         (JSC::DFG::OSRExit::OSRExit):
2386         (JSC::DFG::OSRExit::setPatchableCodeOffset):
2387         * dfg/DFGOSRExit.h:
2388         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
2389         * dfg/DFGOSRExitCompiler.cpp:
2390         * dfg/DFGOSRExitCompiler32_64.cpp:
2391         (JSC::DFG::OSRExitCompiler::compileExit):
2392         * dfg/DFGOSRExitCompiler64.cpp:
2393         (JSC::DFG::OSRExitCompiler::compileExit):
2394         * dfg/DFGOSRExitCompilerCommon.cpp:
2395         (JSC::DFG::osrWriteBarrier):
2396         (JSC::DFG::adjustAndJumpToTarget):
2397         * dfg/DFGOSRExitCompilerCommon.h:
2398         * dfg/DFGPlan.cpp:
2399         (JSC::DFG::Plan::compileInThreadImpl):
2400         * dfg/DFGSlowPathGenerator.h:
2401         (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
2402         (JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
2403         (JSC::DFG::SlowPathGenerator::generate):
2404         * dfg/DFGSpeculativeJIT.h:
2405         * dfg/DFGSpeculativeJIT32_64.cpp:
2406         (JSC::DFG::SpeculativeJIT::cachedGetById):
2407         (JSC::DFG::SpeculativeJIT::cachedPutById):
2408         (JSC::DFG::SpeculativeJIT::emitCall):
2409         * dfg/DFGSpeculativeJIT64.cpp:
2410         (JSC::DFG::SpeculativeJIT::cachedGetById):
2411         (JSC::DFG::SpeculativeJIT::cachedPutById):
2412         (JSC::DFG::SpeculativeJIT::emitCall):
2413         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2414         (JSC::DFG::TierUpCheckInjectionPhase::run):
2415         * ftl/FTLOSRExitCompiler.cpp:
2416         (JSC::FTL::compileStub):
2417         * interpreter/Interpreter.cpp:
2418         (JSC::GetCatchHandlerFunctor::operator()):
2419         (JSC::UnwindFunctor::operator()):
2420         * interpreter/StackVisitor.cpp:
2421         (JSC::StackVisitor::gotoNextFrame):
2422         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
2423         (JSC::StackVisitor::readFrame):
2424         * interpreter/StackVisitor.h:
2425         (JSC::StackVisitor::operator*):
2426         (JSC::StackVisitor::operator->):
2427         * jit/AssemblyHelpers.cpp:
2428         (JSC::AssemblyHelpers::emitExceptionCheck):
2429         (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
2430         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
2431         * jit/AssemblyHelpers.h:
2432         (JSC::AssemblyHelpers::emitCount):
2433         * jit/JITExceptions.cpp:
2434         (JSC::genericUnwind):
2435         * jit/JITOpcodes.cpp:
2436         (JSC::JIT::emit_op_catch):
2437         * jit/JITOpcodes32_64.cpp:
2438         (JSC::JIT::emit_op_catch):
2439         * llint/LowLevelInterpreter32_64.asm:
2440         * llint/LowLevelInterpreter64.asm:
2441         * runtime/VM.h:
2442         (JSC::VM::clearException):
2443         (JSC::VM::clearLastException):
2444         (JSC::VM::addressOfCallFrameForCatch):
2445         (JSC::VM::exception):
2446         (JSC::VM::addressOfException):
2447         * tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
2448         (f):
2449         (bar):
2450         (Foo):
2451         * tests/stress/es6-for-of-loop-exception.js: Added.
2452         (assert):
2453         (shouldThrowInvalidConstAssignment):
2454         (baz):
2455         (foo):
2456         * tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
2457         (assert):
2458         (o.valueOf):
2459         (o.toString):
2460         (read):
2461         (bar):
2462         (foo):
2463         * tests/stress/exception-dfg-not-strict-equal.js: Added.
2464         (foo):
2465         (o.valueOf):
2466         (o.toString):
2467         (assert):
2468         (shouldDoSomethingInFinally):
2469         (catch):
2470         * tests/stress/exception-dfg-operation-read-value.js: Added.
2471         (assert):
2472         (o.valueOf):
2473         (o.toString):
2474         (read):
2475         (foo):
2476         * tests/stress/exception-dfg-throw-from-catch-block.js: Added.
2477         (assert):
2478         (baz):
2479         (bar):
2480         (foo):
2481
2482 2015-09-17  Filip Pizlo  <fpizlo@apple.com>
2483
2484         0.0 should really be 0.0
2485         https://bugs.webkit.org/show_bug.cgi?id=149283
2486
2487         Reviewed by Mark Lam.
2488
2489         A while ago (http://trac.webkit.org/changeset/180813) we introduced the idea that if the
2490         user wrote a number with a decimal point (like "0.0") then we should treat that number as
2491         a double. That's probably a pretty good idea. But, we ended up doing it inconsistently.
2492         The DFG would indeed treat such a number as a double by consulting the
2493         SourceCodeRepresentation, but the other execution engines would still see Int32:0.
2494
2495         This patch makes it consistent.
2496
2497         This is necessary for property type inference to perform well. Otherwise, a store of a
2498         constant would change type from the baseline engine to the DFG, which would then cause
2499         a storm of property type invalidations and recompilations.
2500
2501         * bytecompiler/BytecodeGenerator.cpp:
2502         (JSC::BytecodeGenerator::addConstantValue):
2503
2504 2015-09-17  Filip Pizlo  <fpizlo@apple.com>
2505
2506         stress/exit-from-getter.js.ftl-eager occasionally traps in debug
2507         https://bugs.webkit.org/show_bug.cgi?id=149096
2508
2509         Reviewed by Geoffrey Garen.
2510
2511         JS calls to getters/setters in get/put inline caches need to reset SP after the call, as our
2512         calling convention requires.
2513
2514         * bytecode/PolymorphicAccess.cpp:
2515         (JSC::AccessCase::generate): Fix the bug.
2516         * ftl/FTLLink.cpp:
2517         (JSC::FTL::link): Adds some verbiage about why the FTL stack offset logic is correct.
2518         * tests/stress/getter-arity.js: Added. Other tests would flaky crash before the patch. This test instacrashes before the patch.
2519
2520 2015-09-17  Saam barati  <sbarati@apple.com>
2521
2522         Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions
2523         https://bugs.webkit.org/show_bug.cgi?id=149228
2524
2525         Reviewed by Mark Lam.
2526
2527         op_catch is now responsible for filtering exceptions that
2528         aren't catchable. When op_catch encounters an uncatchable
2529         exception, it will call back into genericUnwind and throw
2530         the exception further down the call stack. This is necessary
2531         in a later patch that will implement exception handling
2532         in the DFG, and part of that patch includes exception
2533         handling that doesn't go through genericUnwind. The DFG try/catch
2534         patch will not go through genericUnwind when it knows that
2535         an exception check after a callOperation will be caught inside the 
2536         machine frame or any inlined frames. This patch enables that 
2537         patch by destroying the notion that all exception handling must 
2538         filter through genericUnwind.
2539
2540         This patch maintains compatibility with the debugger and
2541         profiler by ensuring we notify the debugger when an
2542         exception is thrown inside VM::throwException and not
2543         in genericUnwind. It also notifies the profiler that we've
2544         potentially changed call frames inside op_catch.
2545
2546         * debugger/Debugger.cpp:
2547         (JSC::Debugger::pauseIfNeeded):
2548         * interpreter/Interpreter.cpp:
2549         (JSC::unwindCallFrame):
2550         (JSC::getStackFrameCodeType):
2551         (JSC::UnwindFunctor::operator()):
2552         (JSC::Interpreter::unwind):
2553         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
2554         (JSC::checkedReturn):
2555         * interpreter/Interpreter.h:
2556         (JSC::SuspendExceptionScope::SuspendExceptionScope):
2557         (JSC::SuspendExceptionScope::~SuspendExceptionScope):
2558         (JSC::Interpreter::sampler):
2559         * jit/JIT.h:
2560         * jit/JITInlines.h:
2561         (JSC::JIT::callOperation):
2562         (JSC::JIT::callOperationNoExceptionCheck):
2563         * jit/JITOpcodes.cpp:
2564         (JSC::JIT::emit_op_catch):
2565         * jit/JITOpcodes32_64.cpp:
2566         (JSC::JIT::emit_op_catch):
2567         * jit/JITOperations.cpp:
2568         * jit/JITOperations.h:
2569         * llint/LLIntSlowPaths.cpp:
2570         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2571         (JSC::LLInt::llint_throw_stack_overflow_error):
2572         * llint/LLIntSlowPaths.h:
2573         * llint/LowLevelInterpreter32_64.asm:
2574         * llint/LowLevelInterpreter64.asm:
2575         * runtime/ExceptionHelpers.cpp:
2576         (JSC::isTerminatedExecutionException):
2577         * runtime/VM.cpp:
2578         (JSC::VM::throwException):
2579         * runtime/VM.h:
2580         (JSC::VM::targetMachinePCForThrowOffset):
2581         (JSC::VM::restorePreviousException):
2582         (JSC::VM::clearException):
2583         (JSC::VM::clearLastException):
2584         (JSC::VM::exception):
2585         (JSC::VM::addressOfException):
2586         (JSC::VM::setException):
2587
2588 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2589
2590         Calling a float function on x86 in WebAssembly incorrectly returns a double
2591         https://bugs.webkit.org/show_bug.cgi?id=149254
2592
2593         Reviewed by Michael Saboff.
2594
2595         In WebAssembly on x86 (32-bit), when we call a function that returns a
2596         float or a double, we use the FSTP instruction to read the return value
2597         from the FPU register stack. The FSTP instruction converts the value to
2598         single-precision or double-precision floating-point format, depending on
2599         the destination operand. Currently, we always use double as the
2600         destination, which is wrong. This patch uses the correct return type.
2601         This should fix the test errors in tests/stress/wasm-arithmetic-float32.js
2602
2603         * assembler/X86Assembler.h:
2604         (JSC::X86Assembler::fstps):
2605         * wasm/WASMFunctionCompiler.h:
2606         (JSC::WASMFunctionCompiler::appendCallSetResult):
2607         (JSC::WASMFunctionCompiler::callOperation):
2608
2609 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2610
2611         Save and restore callee save registers in WebAssembly
2612         https://bugs.webkit.org/show_bug.cgi?id=149247
2613
2614         Reviewed by Michael Saboff.
2615
2616         Save callee save registers when entering WebAssembly functions
2617         and restore them when returning.
2618
2619         * jit/RegisterSet.cpp:
2620         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
2621         * jit/RegisterSet.h:
2622         * wasm/WASMFunctionCompiler.h:
2623         (JSC::WASMFunctionCompiler::startFunction):
2624         (JSC::WASMFunctionCompiler::endFunction):
2625         (JSC::WASMFunctionCompiler::buildReturn):
2626         (JSC::WASMFunctionCompiler::localAddress):
2627         (JSC::WASMFunctionCompiler::temporaryAddress):
2628         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
2629         (JSC::WASMFunctionCompiler::callAndUnboxResult):
2630
2631 2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2632
2633         Implement indirect calls in WebAssembly
2634         https://bugs.webkit.org/show_bug.cgi?id=149100
2635
2636         Reviewed by Geoffrey Garen.
2637
2638         This patch implement indirect calls for WebAssembly files generated by
2639         pack-asmjs <https://github.com/WebAssembly/polyfill-prototype-1>.
2640         pack-asmjs uses the same indirect call model as asm.js. In asm.js, an
2641         indirect call looks like this:
2642             t[i & n](...)
2643         where t is a variable referring to an array of functions with the same
2644         signature, i is an integer expression, n is an integer that is equal to
2645         (t.length - 1), and t.length is a power of two. pack-asmjs does not
2646         use the '&' operator nor n in the WebAssembly output, but the semantics
2647         is still the same as asm.js.
2648
2649         * tests/stress/wasm-calls.js:
2650         * tests/stress/wasm/calls.wasm:
2651         * wasm/WASMFormat.h:
2652         * wasm/WASMFunctionCompiler.h:
2653         (JSC::WASMFunctionCompiler::buildCallIndirect):
2654         * wasm/WASMFunctionParser.cpp:
2655         (JSC::WASMFunctionParser::parseExpressionI32):
2656         (JSC::WASMFunctionParser::parseExpressionF32):
2657         (JSC::WASMFunctionParser::parseExpressionF64):
2658         (JSC::WASMFunctionParser::parseCallIndirect):
2659         * wasm/WASMFunctionParser.h:
2660         * wasm/WASMFunctionSyntaxChecker.h:
2661         (JSC::WASMFunctionSyntaxChecker::buildCallIndirect):
2662         * wasm/WASMModuleParser.cpp:
2663         (JSC::WASMModuleParser::parseFunctionPointerTableSection):
2664         (JSC::WASMModuleParser::parseFunctionDefinitionSection):
2665
2666 2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2667
2668         Fix 32-bit build issues in WebAssembly
2669         https://bugs.webkit.org/show_bug.cgi?id=149240
2670
2671         Reviewed by Geoffrey Garen.
2672
2673         Fix the syntax error and replace the instructions that are not available on
2674         64-bit platforms.
2675
2676         * wasm/WASMFunctionCompiler.h:
2677         (JSC::WASMFunctionCompiler::startFunction):
2678         (JSC::WASMFunctionCompiler::endFunction):
2679         (JSC::WASMFunctionCompiler::buildReturn):
2680         (JSC::WASMFunctionCompiler::callAndUnboxResult):
2681         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):
2682
2683 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
2684
2685         JavaScriptCore should discard baseline code after some time
2686         https://bugs.webkit.org/show_bug.cgi?id=149220
2687
2688         Reviewed by Saam Barati.
2689
2690         This is a bit more complicated than discarding optimized code because
2691         the engine previously assumed that we would never discard baseline code.
2692
2693         * bytecode/CodeBlock.cpp:
2694         (JSC::CodeBlock::CodeBlock): Record creation time (and compute time since
2695         creation) instead of install time because CodeBlocks can be installed
2696         more than once, and we don't want to have to worry about edge cases
2697         created by CodeBlocks seeming to get younger.
2698
2699         (JSC::CodeBlock::visitAggregate): Be explicit about only doing the 
2700         weak reference fixpoint for optimized CodeBlocks. We used to avoid the
2701         fixpoint for baseline CodeBlocks implicitly, since they would always
2702         visit themselves strongly right away. But now baseline CodeBlocks might
2703         not visit themselves strongly, since they might choose to jettison due
2704         to old age.
2705
2706         (JSC::CodeBlock::shouldVisitStrongly): Add old age as a reason not to
2707         visit ourselves strongly, so that baseline CodeBlocks can jettison due
2708         to old age.
2709
2710         (JSC::CodeBlock::shouldJettisonDueToWeakReference): Be explicit about
2711         only jettisoning optimized CodeBlocks due to weak references so that we
2712         don't confuse ourselves into thinking that we will jettison a baseline
2713         CodeBlock due to weak references.
2714
2715         (JSC::CodeBlock::shouldJettisonDueToOldAge): Updated to use creation time.
2716
2717         (JSC::CodeBlock::visitOSRExitTargets): Clarify a comment and add an
2718         ASSERT to help record some things I discovered while debugging.
2719
2720         (JSC::CodeBlock::jettison): Allow a baseline CodeBlock to jettison. Don't
2721         assume that we have an alternative or a profiler.
2722
2723         (JSC::CodeBlock::install): Deleted.
2724         * bytecode/CodeBlock.h:
2725         (JSC::CodeBlock::releaseAlternative): Deleted.
2726         (JSC::CodeBlock::setInstallTime): Deleted.
2727         (JSC::CodeBlock::timeSinceInstall): Deleted.
2728
2729         * dfg/DFGOSRExitPreparation.cpp:
2730         (JSC::DFG::prepareCodeOriginForOSRExit): Simplified the computation of
2731         baseline CodeBlock.
2732
2733         * dfg/DFGPlan.cpp:
2734         (JSC::DFG::Plan::checkLivenessAndVisitChildren): Be sure to strongly
2735         visit our inline callframes because we assume that an optimized CodeBlock
2736         will keep its OSR exit targets alive, but the CodeBlock object won't be
2737         able to mark them for itself until compilation has completed (since it
2738         won't have a JITCode object yet).
2739
2740         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
2741         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
2742         Updated for interface change.
2743
2744         * jit/JITCode.h:
2745         (JSC::JITCode::timeToLive): Provide a time to live for interpreter and
2746         baseline code, so they will jettison when old. Use seconds in our
2747         code so that we don't need comments. Make DFG 2X interpreter+baseline,
2748         and FTL 2X DFG+interpreter+baseline, also matching the time we allot
2749         before throwing away all code.
2750
2751         * jit/JITToDFGDeferredCompilationCallback.cpp:
2752         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
2753         * llint/LLIntSlowPaths.cpp:
2754         (JSC::LLInt::jitCompileAndSetHeuristics): Updated for interface change.
2755
2756         * runtime/Executable.cpp:
2757         (JSC::ScriptExecutable::installCode): Allow our caller to install nullptr,
2758         since we need to do this when jettisoning a baseline CodeBlock. Require
2759         our caller to specify the details of the installation because we can't
2760         rely on a non-null CodeBlock in order to compute them.
2761
2762         (JSC::ScriptExecutable::newCodeBlockFor):
2763         (JSC::ScriptExecutable::prepareForExecutionImpl):
2764         * runtime/Executable.h:
2765         (JSC::ScriptExecutable::recordParse): Updated for interface change.
2766
2767         * runtime/Options.h: Renamed the CodeBlock liveness option since it now
2768         controls baseline and optimized code.
2769
2770 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
2771
2772         Remove obsolete code for deleting CodeBlocks
2773         https://bugs.webkit.org/show_bug.cgi?id=149231
2774
2775         Reviewed by Mark Lam.
2776
2777         * heap/Heap.cpp:
2778         (JSC::Heap::deleteAllCodeBlocks): ASSERT that we're called in a valid
2779         state, and do the compiler waiting ourselves instead of having our
2780         caller do it. This is more appropriate to our new limited use.
2781
2782         (JSC::Heap::collectImpl):
2783         (JSC::Heap::deleteOldCode): Deleted. Don't call deleteAllCodeBlocks
2784         periodically because it's not such a good idea to delete everything
2785         at once, and CodeBlocks now have a more precise individual policy for
2786         when to delete. Also, this function used to fail all or nearly all of
2787         the time because its invariants that we were not executing or compiling
2788         could not be met.
2789
2790         * heap/Heap.h:
2791
2792         * jsc.cpp:
2793         (GlobalObject::finishCreation):
2794         (functionDeleteAllCompiledCode): Deleted.
2795         * tests/stress/deleteAllCompiledCode.js: Removed. Removed this testing
2796         code because it did not do what it thought it did. All of this code
2797         was guaranteed to no-op since it would run JavaScript to call a function
2798         that would return early because JavaScript was running.
2799
2800         * runtime/VM.cpp:
2801         (JSC::VM::deleteAllCode): This code is simpler now becaue 
2802         heap.deleteAllCodeBlocks does some work for us.
2803
2804         * runtime/VMEntryScope.cpp:
2805         (JSC::VMEntryScope::VMEntryScope): Don't delete code on VM entry. This
2806         policy was old, and it dated back to a time when we 
2807
2808             (a) couldn't run in the interpreter if compilation failed;
2809
2810             (b) didn't reduce the rate of compilation in response to executable
2811             memory pressure;
2812
2813             (c) didn't throw away individual CodeBlocks automatically.
2814
2815 2015-09-16  Michael Saboff  <msaboff@apple.com>
2816
2817         [ES6] Implement tail calls in the LLInt and Baseline JIT
2818         https://bugs.webkit.org/show_bug.cgi?id=148661
2819
2820         Fix for the breakage of Speedometer/Full.html (https://bugs.webkit.org/show_bug.cgi?id=149162).
2821
2822         Reviewed by Filip Pizlo.
2823         Changed SetupVarargsFrame.cpp::emitSetVarargsFrame to align the callframe size to be a
2824         multiple of stackAlignmentRegisters() in addition to the location of the new frame.
2825
2826         Fixed Reviewed by Filip Pizlo.
2827
2828         * CMakeLists.txt:
2829         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2830         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2831         * JavaScriptCore.xcodeproj/project.pbxproj:
2832         * assembler/AbortReason.h:
2833         * assembler/AbstractMacroAssembler.h:
2834         (JSC::AbstractMacroAssembler::Call::Call):
2835         (JSC::AbstractMacroAssembler::repatchNearCall):
2836         (JSC::AbstractMacroAssembler::repatchCompact):
2837         * assembler/CodeLocation.h:
2838         (JSC::CodeLocationNearCall::CodeLocationNearCall):
2839         (JSC::CodeLocationNearCall::callMode):
2840         (JSC::CodeLocationCommon::callAtOffset):
2841         (JSC::CodeLocationCommon::nearCallAtOffset):
2842         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
2843         * assembler/LinkBuffer.h:
2844         (JSC::LinkBuffer::locationOfNearCall):
2845         (JSC::LinkBuffer::locationOf):
2846         * assembler/MacroAssemblerARM.h:
2847         (JSC::MacroAssemblerARM::nearCall):
2848         (JSC::MacroAssemblerARM::nearTailCall):
2849         (JSC::MacroAssemblerARM::call):
2850         (JSC::MacroAssemblerARM::linkCall):
2851         * assembler/MacroAssemblerARM64.h:
2852         (JSC::MacroAssemblerARM64::nearCall):
2853         (JSC::MacroAssemblerARM64::nearTailCall):
2854         (JSC::MacroAssemblerARM64::ret):
2855         (JSC::MacroAssemblerARM64::linkCall):
2856         * assembler/MacroAssemblerARMv7.h:
2857         (JSC::MacroAssemblerARMv7::nearCall):
2858         (JSC::MacroAssemblerARMv7::nearTailCall):
2859         (JSC::MacroAssemblerARMv7::call):
2860         (JSC::MacroAssemblerARMv7::linkCall):
2861         * assembler/MacroAssemblerMIPS.h:
2862         (JSC::MacroAssemblerMIPS::nearCall):
2863         (JSC::MacroAssemblerMIPS::nearTailCall):
2864         (JSC::MacroAssemblerMIPS::call):
2865         (JSC::MacroAssemblerMIPS::linkCall):
2866         (JSC::MacroAssemblerMIPS::repatchCall):
2867         * assembler/MacroAssemblerSH4.h:
2868         (JSC::MacroAssemblerSH4::call):
2869         (JSC::MacroAssemblerSH4::nearTailCall):
2870         (JSC::MacroAssemblerSH4::nearCall):
2871         (JSC::MacroAssemblerSH4::linkCall):
2872         (JSC::MacroAssemblerSH4::repatchCall):
2873         * assembler/MacroAssemblerX86.h:
2874         (JSC::MacroAssemblerX86::linkCall):
2875         * assembler/MacroAssemblerX86Common.h:
2876         (JSC::MacroAssemblerX86Common::breakpoint):
2877         (JSC::MacroAssemblerX86Common::nearTailCall):
2878         (JSC::MacroAssemblerX86Common::nearCall):
2879         * assembler/MacroAssemblerX86_64.h:
2880         (JSC::MacroAssemblerX86_64::linkCall):
2881         * bytecode/BytecodeList.json:
2882         * bytecode/BytecodeUseDef.h:
2883         (JSC::computeUsesForBytecodeOffset):
2884         (JSC::computeDefsForBytecodeOffset):
2885         * bytecode/CallLinkInfo.h:
2886         (JSC::CallLinkInfo::callTypeFor):
2887         (JSC::CallLinkInfo::isVarargsCallType):
2888         (JSC::CallLinkInfo::CallLinkInfo):
2889         (JSC::CallLinkInfo::specializationKind):
2890         (JSC::CallLinkInfo::callModeFor):
2891         (JSC::CallLinkInfo::callMode):
2892         (JSC::CallLinkInfo::isTailCall):
2893         (JSC::CallLinkInfo::isVarargs):
2894         (JSC::CallLinkInfo::registerPreservationMode):
2895         * bytecode/CallLinkStatus.cpp:
2896         (JSC::CallLinkStatus::computeFromLLInt):
2897         * bytecode/CodeBlock.cpp:
2898         (JSC::CodeBlock::dumpBytecode):
2899         (JSC::CodeBlock::CodeBlock):
2900         * bytecompiler/BytecodeGenerator.cpp:
2901         (JSC::BytecodeGenerator::BytecodeGenerator):
2902         (JSC::BytecodeGenerator::emitCallInTailPosition):
2903         (JSC::BytecodeGenerator::emitCallEval):
2904         (JSC::BytecodeGenerator::emitCall):
2905         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2906         (JSC::BytecodeGenerator::emitConstructVarargs):
2907         * bytecompiler/NodesCodegen.cpp:
2908         (JSC::CallArguments::CallArguments):
2909         (JSC::LabelNode::emitBytecode):
2910         * dfg/DFGByteCodeParser.cpp:
2911         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
2912         * ftl/FTLLowerDFGToLLVM.cpp:
2913         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
2914         * interpreter/Interpreter.h:
2915         (JSC::Interpreter::isCallBytecode):
2916         (JSC::calleeFrameForVarargs):
2917         * jit/CCallHelpers.h:
2918         (JSC::CCallHelpers::jumpToExceptionHandler):
2919         (JSC::CCallHelpers::prepareForTailCallSlow):
2920         * jit/JIT.cpp:
2921         (JSC::JIT::privateCompileMainPass):
2922         (JSC::JIT::privateCompileSlowCases):
2923         * jit/JIT.h:
2924         * jit/JITCall.cpp:
2925         (JSC::JIT::compileOpCall):
2926         (JSC::JIT::compileOpCallSlowCase):
2927         (JSC::JIT::emit_op_call):
2928         (JSC::JIT::emit_op_tail_call):
2929         (JSC::JIT::emit_op_call_eval):
2930         (JSC::JIT::emit_op_call_varargs):
2931         (JSC::JIT::emit_op_tail_call_varargs):
2932         (JSC::JIT::emit_op_construct_varargs):
2933         (JSC::JIT::emitSlow_op_call):
2934         (JSC::JIT::emitSlow_op_tail_call):
2935         (JSC::JIT::emitSlow_op_call_eval):
2936         (JSC::JIT::emitSlow_op_call_varargs):
2937         (JSC::JIT::emitSlow_op_tail_call_varargs):
2938         (JSC::JIT::emitSlow_op_construct_varargs):
2939         * jit/JITCall32_64.cpp:
2940         (JSC::JIT::emitSlow_op_call):
2941         (JSC::JIT::emitSlow_op_tail_call):
2942         (JSC::JIT::emitSlow_op_call_eval):
2943         (JSC::JIT::emitSlow_op_call_varargs):
2944         (JSC::JIT::emitSlow_op_tail_call_varargs):
2945         (JSC::JIT::emitSlow_op_construct_varargs):
2946         (JSC::JIT::emit_op_call):
2947         (JSC::JIT::emit_op_tail_call):
2948         (JSC::JIT::emit_op_call_eval):
2949         (JSC::JIT::emit_op_call_varargs):
2950         (JSC::JIT::emit_op_tail_call_varargs):
2951         (JSC::JIT::emit_op_construct_varargs):
2952         (JSC::JIT::compileOpCall):
2953         (JSC::JIT::compileOpCallSlowCase):
2954         * jit/JITInlines.h:
2955         (JSC::JIT::emitNakedCall):
2956         (JSC::JIT::emitNakedTailCall):
2957         (JSC::JIT::updateTopCallFrame):
2958         * jit/JITOperations.cpp:
2959         * jit/JITOperations.h:
2960         * jit/Repatch.cpp:
2961         (JSC::linkVirtualFor):
2962         (JSC::linkPolymorphicCall):
2963         * jit/SetupVarargsFrame.cpp:
2964         (JSC::emitSetVarargsFrame):
2965         * jit/ThunkGenerators.cpp:
2966         (JSC::throwExceptionFromCallSlowPathGenerator):
2967         (JSC::slowPathFor):
2968         (JSC::linkCallThunkGenerator):
2969         (JSC::virtualThunkFor):
2970         (JSC::arityFixupGenerator):
2971         (JSC::unreachableGenerator):
2972         (JSC::baselineGetterReturnThunkGenerator):
2973         * jit/ThunkGenerators.h:
2974         * llint/LowLevelInterpreter.asm:
2975         * llint/LowLevelInterpreter32_64.asm:
2976         * llint/LowLevelInterpreter64.asm:
2977         * runtime/CommonSlowPaths.h:
2978         (JSC::CommonSlowPaths::arityCheckFor):
2979         (JSC::CommonSlowPaths::opIn):
2980
2981 2015-09-15  Michael Saboff  <msaboff@apple.com>
2982
2983         Rollout r189774 and 189818.
2984
2985         Broke Speedometer/Full.html
2986
2987         Not reviewed.
2988
2989         * CMakeLists.txt:
2990         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2991         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2992         * JavaScriptCore.xcodeproj/project.pbxproj:
2993         * assembler/AbortReason.h:
2994         * assembler/AbstractMacroAssembler.h:
2995         (JSC::AbstractMacroAssembler::Call::Call):
2996         (JSC::AbstractMacroAssembler::repatchNearCall):
2997         (JSC::AbstractMacroAssembler::repatchCompact):
2998         * assembler/CodeLocation.h:
2999         (JSC::CodeLocationNearCall::CodeLocationNearCall):
3000         (JSC::CodeLocationCommon::callAtOffset):
3001         (JSC::CodeLocationCommon::nearCallAtOffset):
3002         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
3003         (JSC::CodeLocationNearCall::callMode): Deleted.
3004         * assembler/LinkBuffer.h:
3005         (JSC::LinkBuffer::locationOfNearCall):
3006         (JSC::LinkBuffer::locationOf):
3007         * assembler/MacroAssemblerARM.h:
3008         (JSC::MacroAssemblerARM::nearCall):
3009         (JSC::MacroAssemblerARM::call):
3010         (JSC::MacroAssemblerARM::linkCall):
3011         (JSC::MacroAssemblerARM::nearTailCall): Deleted.
3012         * assembler/MacroAssemblerARM64.h:
3013         (JSC::MacroAssemblerARM64::nearCall):
3014         (JSC::MacroAssemblerARM64::ret):
3015         (JSC::MacroAssemblerARM64::linkCall):
3016         (JSC::MacroAssemblerARM64::nearTailCall): Deleted.
3017         * assembler/MacroAssemblerARMv7.h:
3018         (JSC::MacroAssemblerARMv7::nearCall):
3019         (JSC::MacroAssemblerARMv7::call):
3020         (JSC::MacroAssemblerARMv7::linkCall):
3021         (JSC::MacroAssemblerARMv7::nearTailCall): Deleted.
3022         * assembler/MacroAssemblerMIPS.h:
3023         (JSC::MacroAssemblerMIPS::nearCall):
3024         (JSC::MacroAssemblerMIPS::call):
3025         (JSC::MacroAssemblerMIPS::linkCall):
3026         (JSC::MacroAssemblerMIPS::repatchCall):
3027         (JSC::MacroAssemblerMIPS::nearTailCall): Deleted.
3028         * assembler/MacroAssemblerSH4.h:
3029         (JSC::MacroAssemblerSH4::call):
3030         (JSC::MacroAssemblerSH4::nearCall):
3031         (JSC::MacroAssemblerSH4::linkCall):
3032         (JSC::MacroAssemblerSH4::repatchCall):
3033         (JSC::MacroAssemblerSH4::nearTailCall): Deleted.
3034         * assembler/MacroAssemblerX86.h:
3035         (JSC::MacroAssemblerX86::linkCall):
3036         * assembler/MacroAssemblerX86Common.h:
3037         (JSC::MacroAssemblerX86Common::breakpoint):
3038         (JSC::MacroAssemblerX86Common::nearCall):
3039         (JSC::MacroAssemblerX86Common::nearTailCall): Deleted.
3040         * assembler/MacroAssemblerX86_64.h:
3041         (JSC::MacroAssemblerX86_64::linkCall):
3042         * bytecode/BytecodeList.json:
3043         * bytecode/BytecodeUseDef.h:
3044         (JSC::computeUsesForBytecodeOffset):
3045         (JSC::computeDefsForBytecodeOffset):
3046         * bytecode/CallLinkInfo.h:
3047         (JSC::CallLinkInfo::callTypeFor):
3048         (JSC::CallLinkInfo::CallLinkInfo):
3049         (JSC::CallLinkInfo::specializationKind):
3050         (JSC::CallLinkInfo::registerPreservationMode):
3051         (JSC::CallLinkInfo::isVarargsCallType): Deleted.
3052         (JSC::CallLinkInfo::callModeFor): Deleted.
3053         (JSC::CallLinkInfo::callMode): Deleted.
3054         (JSC::CallLinkInfo::isTailCall): Deleted.
3055         (JSC::CallLinkInfo::isVarargs): Deleted.
3056         * bytecode/CallLinkStatus.cpp:
3057         (JSC::CallLinkStatus::computeFromLLInt):
3058         * bytecode/CodeBlock.cpp:
3059         (JSC::CodeBlock::dumpBytecode):
3060         (JSC::CodeBlock::CodeBlock):
3061         * bytecompiler/BytecodeGenerator.cpp:
3062         (JSC::BytecodeGenerator::BytecodeGenerator):
3063         (JSC::BytecodeGenerator::emitCallInTailPosition):
3064         (JSC::BytecodeGenerator::emitCallEval):
3065         (JSC::BytecodeGenerator::emitCall):
3066         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
3067         (JSC::BytecodeGenerator::emitConstructVarargs):
3068         * bytecompiler/NodesCodegen.cpp:
3069         (JSC::CallArguments::CallArguments):
3070         (JSC::LabelNode::emitBytecode):
3071         * dfg/DFGByteCodeParser.cpp:
3072         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
3073         * ftl/FTLLowerDFGToLLVM.cpp:
3074         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
3075         * interpreter/Interpreter.h:
3076         (JSC::Interpreter::isCallBytecode):
3077         * jit/CCallHelpers.h:
3078         (JSC::CCallHelpers::jumpToExceptionHandler):
3079         (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
3080         * jit/JIT.cpp:
3081         (JSC::JIT::privateCompileMainPass):
3082         (JSC::JIT::privateCompileSlowCases):
3083         * jit/JIT.h:
3084         * jit/JITCall.cpp:
3085         (JSC::JIT::compileOpCall):
3086         (JSC::JIT::compileOpCallSlowCase):
3087         (JSC::JIT::emit_op_call):
3088         (JSC::JIT::emit_op_call_eval):
3089         (JSC::JIT::emit_op_call_varargs):
3090         (JSC::JIT::emit_op_construct_varargs):
3091         (JSC::JIT::emitSlow_op_call):
3092         (JSC::JIT::emitSlow_op_call_eval):
3093         (JSC::JIT::emitSlow_op_call_varargs):
3094         (JSC::JIT::emitSlow_op_construct_varargs):
3095         (JSC::JIT::emit_op_tail_call): Deleted.
3096         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
3097         (JSC::JIT::emitSlow_op_tail_call): Deleted.
3098         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
3099         * jit/JITCall32_64.cpp:
3100         (JSC::JIT::emitSlow_op_call):
3101         (JSC::JIT::emitSlow_op_call_eval):
3102         (JSC::JIT::emitSlow_op_call_varargs):
3103         (JSC::JIT::emitSlow_op_construct_varargs):
3104         (JSC::JIT::emit_op_call):
3105         (JSC::JIT::emit_op_call_eval):
3106         (JSC::JIT::emit_op_call_varargs):
3107         (JSC::JIT::emit_op_construct_varargs):
3108         (JSC::JIT::compileOpCall):
3109         (JSC::JIT::compileOpCallSlowCase):
3110         (JSC::JIT::emitSlow_op_tail_call): Deleted.
3111         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
3112         (JSC::JIT::emit_op_tail_call): Deleted.
3113         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
3114         * jit/JITInlines.h:
3115         (JSC::JIT::emitNakedCall):
3116         (JSC::JIT::updateTopCallFrame):
3117         (JSC::JIT::emitNakedTailCall): Deleted.
3118         * jit/JITOperations.cpp:
3119         * jit/JITOperations.h:
3120         * jit/Repatch.cpp:
3121         (JSC::linkVirtualFor):
3122         (JSC::linkPolymorphicCall):
3123         * jit/ThunkGenerators.cpp:
3124         (JSC::throwExceptionFromCallSlowPathGenerator):
3125         (JSC::slowPathFor):
3126         (JSC::linkCallThunkGenerator):
3127         (JSC::virtualThunkFor):
3128         (JSC::arityFixupGenerator):
3129         (JSC::baselineGetterReturnThunkGenerator):
3130         (JSC::unreachableGenerator): Deleted.
3131         * jit/ThunkGenerators.h:
3132         * llint/LowLevelInterpreter.asm:
3133         * llint/LowLevelInterpreter32_64.asm:
3134         * llint/LowLevelInterpreter64.asm:
3135         * runtime/CommonSlowPaths.h:
3136         (JSC::CommonSlowPaths::arityCheckFor):
3137         (JSC::CommonSlowPaths::opIn):
3138         * tests/stress/mutual-tail-call-no-stack-overflow.js: Removed.
3139         * tests/stress/tail-call-no-stack-overflow.js: Removed.
3140         * tests/stress/tail-call-recognize.js: Removed.
3141         * tests/stress/tail-call-varargs-no-stack-overflow.js: Removed.
3142         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Removed.
3143
3144 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3145
3146         Implement imported global variables in WebAssembly
3147         https://bugs.webkit.org/show_bug.cgi?id=149206
3148
3149         Reviewed by Filip Pizlo.
3150
3151         Values can now be imported to a WebAssembly module through properties of
3152         the imports object that is passed to loadWebAssembly(). In order to
3153         avoid any side effect when accessing the imports object, we check that
3154         the properties are data properties. We also check that each value is a
3155         primitive and is not a Symbol. According to the ECMA262 6.0 spec,
3156         calling ToNumber() on a primitive that is not a Symbol should not cause
3157         any side effect.[1]
3158
3159         [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-tonumber
3160
3161         * tests/stress/wasm-globals.js:
3162         * tests/stress/wasm/globals.wasm:
3163         * wasm/WASMModuleParser.cpp:
3164         (JSC::WASMModuleParser::parseModule):
3165         (JSC::WASMModuleParser::parseGlobalSection):
3166         * wasm/WASMModuleParser.h:
3167
3168 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3169
3170         Fix asm.js errors in WebAssembly tests
3171         https://bugs.webkit.org/show_bug.cgi?id=149203
3172
3173         Reviewed by Geoffrey Garen.
3174
3175         Our WebAssembly implementation uses asm.js for testing. Using Firefox to
3176         parse asm.js reveals many errors that are not caught by pack-asmjs. For
3177         example,
3178         - asm.js does not allow the use of the multiplication operator (*) to
3179           multiply two integers, because the result can be so large that some
3180           lower bits of precision are lost. Math.imul is used instead.
3181         - an int variable must be coerced to either signed (via x|0) or unsigned
3182           (via x>>>0) before it's returned.
3183
3184         * tests/stress/wasm-arithmetic-int32.js:
3185         * tests/stress/wasm-calls.js:
3186         * tests/stress/wasm-control-flow.js:
3187         * tests/stress/wasm-globals.js:
3188         * tests/stress/wasm-locals.js:
3189         * tests/stress/wasm-relational.js:
3190         * tests/stress/wasm/control-flow.wasm:
3191
3192 2015-09-15  Ryosuke Niwa  <rniwa@webkit.org>
3193
3194         Add ShadowRoot interface and Element.prototype.attachShadow
3195         https://bugs.webkit.org/show_bug.cgi?id=149187
3196
3197         Reviewed by Antti Koivisto.
3198
3199         * Configurations/FeatureDefines.xcconfig:
3200
3201 2015-09-15  Joseph Pecoraro  <pecoraro@apple.com>
3202
3203         Web Inspector: Paused Debugger prevents page reload
3204         https://bugs.webkit.org/show_bug.cgi?id=148174
3205
3206         Reviewed by Brian Burg.
3207
3208         * debugger/Debugger.h:
3209         (JSC::Debugger::suppressAllPauses):
3210         (JSC::Debugger::setSuppressAllPauses):
3211         * debugger/Debugger.cpp:
3212         (JSC::Debugger::Debugger):
3213         (JSC::Debugger::pauseIfNeeded):
3214         * inspector/agents/InspectorDebuggerAgent.h:
3215         * inspector/agents/InspectorDebuggerAgent.cpp:
3216         (Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
3217         Provide a way to suppress pauses.
3218
3219 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3220
3221         Implement calls to JavaScript functions in WebAssembly
3222         https://bugs.webkit.org/show_bug.cgi?id=149093
3223
3224         Reviewed by Filip Pizlo.
3225
3226         This patch implements calls to JavaScript functions in WebAssembly.
3227         WebAssembly functions can only call JavaScript functions that are
3228         imported to their module via an object that is passed into
3229         loadWebAssembly(). References to JavaScript functions are resolved at
3230         the module's load time, just like asm.js.
3231
3232         * jsc.cpp:
3233         (GlobalObject::finishCreation):
3234         (functionLoadWebAssembly):
3235         * tests/stress/wasm-calls.js:
3236         * tests/stress/wasm/calls.wasm:
3237         * wasm/JSWASMModule.cpp:
3238         (JSC::JSWASMModule::visitChildren):
3239         * wasm/JSWASMModule.h:
3240         (JSC::JSWASMModule::importedFunctions):
3241         * wasm/WASMFunctionCompiler.h:
3242         (JSC::WASMFunctionCompiler::buildCallImport):
3243         * wasm/WASMFunctionParser.cpp:
3244         (JSC::WASMFunctionParser::parseExpressionI32):
3245         (JSC::WASMFunctionParser::parseExpressionF64):
3246         (JSC::WASMFunctionParser::parseCallImport):
3247         * wasm/WASMFunctionParser.h:
3248         * wasm/WASMFunctionSyntaxChecker.h:
3249         (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
3250         (JSC::WASMFunctionSyntaxChecker::buildCallImport):
3251         (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):
3252         * wasm/WASMModuleParser.cpp:
3253         (JSC::WASMModuleParser::WASMModuleParser):
3254         (JSC::WASMModuleParser::parse):
3255         (JSC::WASMModuleParser::parseModule):
3256         (JSC::WASMModuleParser::parseFunctionImportSection):
3257         (JSC::WASMModuleParser::getImportedValue):
3258         (JSC::parseWebAssembly):
3259         * wasm/WASMModuleParser.h:
3260
3261 2015-09-15  Csaba Osztrogon√°c  <ossy@webkit.org>
3262
3263         Fix the !ENABLE(DFG_JIT) build after r188696
3264         https://bugs.webkit.org/show_bug.cgi?id=149158
3265
3266         Reviewed by Yusuke Suzuki.
3267
3268         * bytecode/GetByIdStatus.cpp:
3269         * bytecode/GetByIdStatus.h:
3270
3271 2015-09-15  Saam barati  <sbarati@apple.com>
3272
3273         functions that use try/catch will allocate a top level JSLexicalEnvironment even when it is not necessary
3274         https://bugs.webkit.org/show_bug.cgi?id=148169
3275
3276         Reviewed by Geoffrey Garen.
3277
3278         We used to do this before we had proper lexical scoping
3279         in the bytecode generator. There is absolutely no reason
3280         why need to allocate a top-level "var" activation when a
3281         function/program uses a "catch" block.
3282
3283         * parser/ASTBuilder.h:
3284         (JSC::ASTBuilder::createTryStatement):
3285         (JSC::ASTBuilder::incConstants):
3286         (JSC::ASTBuilder::usesThis):
3287         (JSC::ASTBuilder::usesArguments):
3288         (JSC::ASTBuilder::usesWith):
3289         (JSC::ASTBuilder::usesEval):
3290         (JSC::ASTBuilder::usesCatch): Deleted.
3291         * parser/Nodes.h:
3292         (JSC::ScopeNode::isStrictMode):
3293         (JSC::ScopeNode::setUsesArguments):
3294         (JSC::ScopeNode::usesThis):
3295         (JSC::ScopeNode::needsActivation):
3296         (JSC::ScopeNode::hasCapturedVariables):
3297         (JSC::ScopeNode::captures):
3298         (JSC::ScopeNode::needsActivationForMoreThanVariables): Deleted.
3299         * parser/ParserModes.h:
3300         * runtime/Executable.h:
3301         (JSC::ScriptExecutable::usesEval):
3302         (JSC::ScriptExecutable::usesArguments):
3303         (JSC::ScriptExecutable::needsActivation):
3304         (JSC::ScriptExecutable::isStrictMode):
3305         (JSC::ScriptExecutable::ecmaMode):
3306
3307 2015-09-15  Michael Saboff  <msaboff@apple.com>
3308
3309         REGRESSION(r189774): CLoop doesn't build after r189774
3310         https://bugs.webkit.org/show_bug.cgi?id=149171
3311
3312         Unreviewed build fix for the C Loop.
3313
3314         Added needed C Loop label opcodes.
3315
3316         * bytecode/BytecodeList.json:
3317
3318 2015-09-15  Andy VanWagoner  <thetalecrafter@gmail.com>
3319
3320         [INTL] Implement supportedLocalesOf on Intl Constructors
3321         https://bugs.webkit.org/show_bug.cgi?id=147599
3322
3323         Reviewed by Benjamin Poulain.
3324
3325         Implements all of the abstract operations used by supportedLocalesOf,
3326         except during canonicalization it does not replace redundant tags,
3327         or subtags with their preferred values.
3328
3329         * icu/unicode/ucal.h: Added.
3330         * icu/unicode/udat.h: Added.
3331         * icu/unicode/umisc.h: Added.
3332         * icu/unicode/unum.h: Added.
3333         * icu/unicode/utypes.h: Clear the U_SHOW_CPLUSPLUS_API flag to prevent C++ headers from being included.
3334         * runtime/CommonIdentifiers.h: Adde localeMatcher.
3335         * runtime/IntlCollatorConstructor.cpp:
3336         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Implemented.
3337         * runtime/IntlDateTimeFormatConstructor.cpp:
3338         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Implemented.
3339         * runtime/IntlNumberFormatConstructor.cpp:
3340         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Implemented.
3341         * runtime/IntlObject.cpp:
3342         (JSC::canonicalizeLanguageTag):
3343         (JSC::getCanonicalLangTag):
3344         (JSC::getPrivateUseLangTag):
3345         (JSC::getGrandfatheredLangTag):
3346         (JSC::canonicalizeLocaleList):
3347         (JSC::bestAvailableLocale):
3348         (JSC::lookupSupportedLocales):
3349         (JSC::bestFitSupportedLocales):
3350         (JSC::supportedLocales):
3351         (JSC::getIntlStringOption):
3352         (JSC::getIntlBooleanOption):
3353         * runtime/IntlObject.h:
3354         * runtime/JSCJSValue.h: Added toLength.
3355         * runtime/JSCJSValue.cpp: Added toLength.
3356         (JSC::JSValue::toLength): Implement ToLength from ECMA 262 6.0 7.1.15
3357         * runtime/JSGlobalObject.cpp:
3358         (JSC::JSGlobalObject::intlCollatorAvailableLocales): Added lazy locale list.
3359         (JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales): Added lazy locale list.
3360         (JSC::JSGlobalObject::intlNumberFormatAvailableLocales): Added lazy locale list.
3361         * runtime/JSGlobalObject.h:
3362
3363 2015-09-14  Saam barati  <sbarati@apple.com>
3364
3365         rename callFrameForThrow to callFrameForCatch
3366         https://bugs.webkit.org/show_bug.cgi?id=149136
3367
3368         Reviewed by Michael Saboff.
3369
3370         We use "callFrameForThrow" to mean the call frame in
3371         which we're catching the exception. The field name
3372         should accurately represent its purpose by being
3373         named "callFrameForCatch".
3374
3375         * jit/CCallHelpers.h:
3376         (JSC::CCallHelpers::jumpToExceptionHandler):
3377         * jit/JITExceptions.cpp:
3378         (JSC::genericUnwind):
3379         * jit/JITOpcodes.cpp:
3380         (JSC::JIT::emit_op_catch):
3381         * jit/JITOpcodes32_64.cpp:
3382         (JSC::JIT::emit_op_catch):
3383         * jit/JITOperations.cpp:
3384         * llint/LowLevelInterpreter32_64.asm:
3385         * llint/LowLevelInterpreter64.asm:
3386         * runtime/VM.h:
3387         (JSC::VM::exceptionOffset):
3388         (JSC::VM::callFrameForCatchOffset):
3389         (JSC::VM::targetMachinePCForThrowOffset):
3390         (JSC::VM::callFrameForThrowOffset): Deleted.
3391
3392 2015-09-14  Basile Clement  <basile_clement@apple.com>
3393
3394         [ES6] Implement tail calls in the LLInt and Baseline JIT
3395         https://bugs.webkit.org/show_bug.cgi?id=148661
3396
3397         Reviewed by Filip Pizlo.
3398
3399         This patch introduces two new opcodes, op_tail_call and
3400         op_tail_call_varargs, to perform tail calls, and implements them in the
3401         LLInt and baseline JIT. Their use prevents DFG and FTL compilation for
3402         now. They are currently implemented by sliding the call frame and
3403         masquerading as our own caller right before performing an actual call.
3404
3405         This required to change the operationLink family of operation to return
3406         a SlowPathReturnType instead of a char* in order to distinguish between
3407         exception cases and actual call cases. We introduce a new FrameAction
3408         enum that indicates whether to reuse (non-exceptional tail call) or
3409         keep the current call frame (non-tail call, and exceptional cases).
3410
3411         This is also a semantics change, since the Function.caller property is
3412         now leaking tail calls. Since tail calls are only used in strict mode,
3413         which poisons this property, the only way of seeing this semantics
3414         change is when a sloppy function calls a strict function that then
3415         tail-calls a sloppy function. Previously, the second sloppy function's
3416         caller would have been the strict function (i.e. raises a TypeError
3417         when the .caller attribute is accessed), while it is now the first
3418         sloppy function. Tests have been updated to reflect that.
3419
3420         This also changes the assumptions we make about call frames. In order
3421         to be relatively efficient, we want to be able to compute the frame
3422         size based only on the argument count, which was not possible
3423         previously. To enable this, we now enforce at the bytecode generator,
3424         DFG and FTL level that any space reserved for a call frame is
3425         stack-aligned, which allows to easily compute its size when performing
3426         a tail call. In all the "special call cases" (calls from native code,
3427         inlined cache calls, etc.), we are starting the frame at the current
3428         stack pointer and thus will always have a stack-aligned frame size.
3429
3430         Finally, this patch adds a couple of tests to check that tail calls run
3431         in constant stack space, as well as tests checking that tail calls are
3432         recognized correctly. Those tests use the handy aforementioned leaking
3433         of tail calls through Function.caller to detect tail calls. 
3434
3435         Given that this patch only implements tail calls for the LLInt and
3436         Baseline JIT, tail calls are disabled by default.  Until changes are
3437         landed for all tiers, tail call testing and use requires the
3438         --enableTailCalls=true or equivalent.
3439
3440         * CMakeLists.txt:
3441         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3442         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3443         * JavaScriptCore.xcodeproj/project.pbxproj:
3444         * assembler/AbortReason.h:
3445         * assembler/AbstractMacroAssembler.h:
3446         (JSC::AbstractMacroAssembler::Call::Call):
3447         (JSC::AbstractMacroAssembler::repatchNearCall):
3448         (JSC::AbstractMacroAssembler::repatchCompact):
3449         * assembler/CodeLocation.h:
3450         (JSC::CodeLocationNearCall::CodeLocationNearCall):
3451         (JSC::CodeLocationNearCall::callMode):
3452         (JSC::CodeLocationCommon::callAtOffset):
3453         (JSC::CodeLocationCommon::nearCallAtOffset):
3454         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
3455         * assembler/LinkBuffer.h:
3456         (JSC::LinkBuffer::locationOfNearCall):
3457         (JSC::LinkBuffer::locationOf):
3458         * assembler/MacroAssemblerARM.h:
3459         (JSC::MacroAssemblerARM::nearCall):
3460         (JSC::MacroAssemblerARM::nearTailCall):
3461         (JSC::MacroAssemblerARM::call):
3462         (JSC::MacroAssemblerARM::linkCall):
3463         * assembler/MacroAssemblerARM64.h:
3464         (JSC::MacroAssemblerARM64::nearCall):
3465         (JSC::MacroAssemblerARM64::nearTailCall):
3466         (JSC::MacroAssemblerARM64::ret):
3467         (JSC::MacroAssemblerARM64::linkCall):
3468         * assembler/MacroAssemblerARMv7.h:
3469         (JSC::MacroAssemblerARMv7::nearCall):
3470         (JSC::MacroAssemblerARMv7::nearTailCall):
3471         (JSC::MacroAssemblerARMv7::call):
3472         (JSC::MacroAssemblerARMv7::linkCall):
3473         * assembler/MacroAssemblerMIPS.h:
3474         (JSC::MacroAssemblerMIPS::nearCall):
3475         (JSC::MacroAssemblerMIPS::nearTailCall):
3476         (JSC::MacroAssemblerMIPS::call):
3477         (JSC::MacroAssemblerMIPS::linkCall):
3478         (JSC::MacroAssemblerMIPS::repatchCall):
3479         * assembler/MacroAssemblerSH4.h:
3480         (JSC::MacroAssemblerSH4::call):
3481         (JSC::MacroAssemblerSH4::nearTailCall):
3482         (JSC::MacroAssemblerSH4::nearCall):
3483         (JSC::MacroAssemblerSH4::linkCall):
3484         (JSC::MacroAssemblerSH4::repatchCall):
3485         * assembler/MacroAssemblerX86.h:
3486         (JSC::MacroAssemblerX86::linkCall):
3487         * assembler/MacroAssemblerX86Common.h:
3488         (JSC::MacroAssemblerX86Common::breakpoint):
3489         (JSC::MacroAssemblerX86Common::nearTailCall):
3490         (JSC::MacroAssemblerX86Common::nearCall):
3491         * assembler/MacroAssemblerX86_64.h:
3492         (JSC::MacroAssemblerX86_64::linkCall):
3493         * bytecode/BytecodeList.json:
3494         * bytecode/BytecodeUseDef.h:
3495         (JSC::computeUsesForBytecodeOffset):
3496         (JSC::computeDefsForBytecodeOffset):
3497         * bytecode/CallLinkInfo.h:
3498         (JSC::CallLinkInfo::callTypeFor):
3499         (JSC::CallLinkInfo::isVarargsCallType):
3500         (JSC::CallLinkInfo::CallLinkInfo):
3501         (JSC::CallLinkInfo::specializationKind):
3502         (JSC::CallLinkInfo::callModeFor):
3503         (JSC::CallLinkInfo::callMode):
3504         (JSC::CallLinkInfo::isTailCall):
3505         (JSC::CallLinkInfo::isVarargs):
3506         (JSC::CallLinkInfo::registerPreservationMode):
3507         * bytecode/CallLinkStatus.cpp:
3508         (JSC::CallLinkStatus::computeFromLLInt):
3509         * bytecode/CallMode.cpp: Added.
3510         (WTF::printInternal):
3511         * bytecode/CallMode.h: Added.
3512         * bytecode/CodeBlock.cpp:
3513         (JSC::CodeBlock::dumpBytecode):
3514         (JSC::CodeBlock::CodeBlock):
3515         * bytecompiler/BytecodeGenerator.cpp:
3516         (JSC::BytecodeGenerator::BytecodeGenerator):
3517         (JSC::BytecodeGenerator::emitCallInTailPosition):
3518         (JSC::BytecodeGenerator::emitCallEval):
3519         (JSC::BytecodeGenerator::emitCall):
3520         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
3521         (JSC::BytecodeGenerator::emitConstructVarargs):
3522         * bytecompiler/NodesCodegen.cpp:
3523         (JSC::CallArguments::CallArguments):
3524         (JSC::LabelNode::emitBytecode):
3525         * dfg/DFGByteCodeParser.cpp:
3526         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
3527         * ftl/FTLLowerDFGToLLVM.cpp:
3528         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
3529         * interpreter/Interpreter.h:
3530         (JSC::Interpreter::isCallBytecode):
3531         * jit/CCallHelpers.h:
3532         (JSC::CCallHelpers::jumpToExceptionHandler):
3533         (JSC::CCallHelpers::prepareForTailCallSlow):
3534         * jit/JIT.cpp:
3535         (JSC::JIT::privateCompileMainPass):
3536         (JSC::JIT::privateCompileSlowCases):
3537         * jit/JIT.h:
3538         * jit/JITCall.cpp:
3539         (JSC::JIT::compileOpCall):
3540         (JSC::JIT::compileOpCallSlowCase):
3541         (JSC::JIT::emit_op_call):
3542         (JSC::JIT::emit_op_tail_call):
3543         (JSC::JIT::emit_op_call_eval):
3544         (JSC::JIT::emit_op_call_varargs):
3545         (JSC::JIT::emit_op_tail_call_varargs):
3546         (JSC::JIT::emit_op_construct_varargs):
3547         (JSC::JIT::emitSlow_op_call):
3548         (JSC::JIT::emitSlow_op_tail_call):
3549         (JSC::JIT::emitSlow_op_call_eval):
3550         (JSC::JIT::emitSlow_op_call_varargs):
3551         (JSC::JIT::emitSlow_op_tail_call_varargs):
3552         (JSC::JIT::emitSlow_op_construct_varargs):
3553         * jit/JITCall32_64.cpp:
3554         (JSC::JIT::emitSlow_op_call):
3555         (JSC::JIT::emitSlow_op_tail_call):
3556         (JSC::JIT::emitSlow_op_call_eval):
3557         (JSC::JIT::emitSlow_op_call_varargs):
3558         (JSC::JIT::emitSlow_op_tail_call_varargs):
3559         (JSC::JIT::emitSlow_op_construct_varargs):
3560         (JSC::JIT::emit_op_call):
3561         (JSC::JIT::emit_op_tail_call):
3562         (JSC::JIT::emit_op_call_eval):
3563         (JSC::JIT::emit_op_call_varargs):
3564         (JSC::JIT::emit_op_tail_call_varargs):
3565         (JSC::JIT::emit_op_construct_varargs):
3566         (JSC::JIT::compileOpCall):
3567         (JSC::JIT::compileOpCallSlowCase):
3568         * jit/JITInlines.h:
3569         (JSC::JIT::emitNakedCall):
3570         (JSC::JIT::emitNakedTailCall):
3571         (JSC::JIT::updateTopCallFrame):
3572         * jit/JITOperations.cpp:
3573         * jit/JITOperations.h:
3574         * jit/Repatch.cpp:
3575         (JSC::linkVirtualFor):
3576         (JSC::linkPolymorphicCall):
3577         * jit/ThunkGenerators.cpp:
3578         (JSC::throwExceptionFromCallSlowPathGenerator):
3579         (JSC::slowPathFor):
3580         (JSC::linkCallThunkGenerator):
3581         (JSC::virtualThunkFor):
3582         (JSC::arityFixupGenerator):
3583         (JSC::unreachableGenerator):
3584         (JSC::baselineGetterReturnThunkGenerator):
3585         * jit/ThunkGenerators.h:
3586         * llint/LowLevelInterpreter.asm:
3587         * llint/LowLevelInterpreter32_64.asm:
3588         * llint/LowLevelInterpreter64.asm:
3589         * runtime/CommonSlowPaths.h:
3590         (JSC::CommonSlowPaths::arityCheckFor):
3591         (JSC::CommonSlowPaths::opIn):
3592         * runtime/Options.h:
3593         * tests/stress/mutual-tail-call-no-stack-overflow.js: Added.
3594         (shouldThrow):
3595         (sloppyCountdown.even):
3596         (sloppyCountdown.odd):
3597         (strictCountdown.even):
3598         (strictCountdown.odd):
3599         (strictCountdown):
3600         (odd):
3601         (even):
3602         * tests/stress/tail-call-no-stack-overflow.js: Added.
3603         (shouldThrow):
3604         (strictLoop):
3605         (strictLoopArityFixup1):
3606         (strictLoopArityFixup2):
3607         * tests/stress/tail-call-recognize.js: Added.
3608         (callerMustBeRun):
3609         (callerMustBeStrict):
3610         (runTests):
3611         * tests/stress/tail-call-varargs-no-stack-overflow.js: Added.
3612         (shouldThrow):
3613         (strictLoop):
3614         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Added.
3615         (tail):
3616         (obj.method):
3617         (obj.get fromNative):
3618         (getThis):
3619
3620 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
3621
3622         LLInt get/put inline caches shouldn't use tons of opcodes
3623         https://bugs.webkit.org/show_bug.cgi?id=149106
3624
3625         Reviewed by Geoffrey Garen.
3626
3627         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
3628         example, instead of having get_by_id branch on the kind of offset (inline or
3629         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
3630         But the problem with this approach is that it doesn't scale. In the property type
3631         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
3632         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
3633         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
3634         checks, we'd have 6 * 11 = 66 variants of put_by_id).
3635
3636         So, this patch completely changes the strategy to mostly using branching inside the
3637         opcode implementation. It's unlikely to have a performance effect. For example, the long
3638         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
3639         and yet nobody noticed. The regression was because the inline cache was in terms of the
3640         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
3641         didn't notice that, then we probably won't notice a couple new branches. (Also, this
3642         patch fixes that regression - the code no longer does such lookups except in the one
3643         unavoidable case in put_by_id transition chain checking.)
3644
3645         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
3646         this flags field to encode the desired type check in bug 148610.
3647
3648         This patch has no effect on performance according to run-jsc-benchmarks.
3649
3650         Relanding this patch with LLInt fixes for non-x86. Previous attempts to fix non-x86 LLInt
3651         build also caused every 64-bit test to crash on every platform. So the patch got rolled
3652         out. This fixes the non-x86 LLInt build while also ensuring that 64-bit platforms don't
3653         crash.
3654
3655         * CMakeLists.txt:
3656         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3657         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3658         * JavaScriptCore.xcodeproj/project.pbxproj:
3659         * bytecode/BytecodeList.json:
3660         * bytecode/BytecodeUseDef.h:
3661         (JSC::computeUsesForBytecodeOffset):
3662         (JSC::computeDefsForBytecodeOffset):
3663         * bytecode/CodeBlock.cpp:
3664         (JSC::CodeBlock::printGetByIdOp):
3665         (JSC::CodeBlock::printGetByIdCacheStatus):
3666         (JSC::CodeBlock::printPutByIdCacheStatus):
3667         (JSC::CodeBlock::dumpBytecode):
3668         (JSC::CodeBlock::CodeBlock):
3669         (JSC::CodeBlock::propagateTransitions):
3670         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3671         * bytecode/CodeBlock.h:
3672         * bytecode/GetByIdStatus.cpp:
3673         (JSC::GetByIdStatus::computeFromLLInt):
3674         * bytecode/Instruction.h:
3675         (JSC::Instruction::Instruction):
3676         * bytecode/PutByIdFlags.cpp: Added.
3677         (WTF::printInternal):
3678         * bytecode/PutByIdFlags.h: Added.
3679         * bytecode/PutByIdStatus.cpp:
3680         (JSC::PutByIdStatus::computeFromLLInt):
3681         * bytecode/UnlinkedCodeBlock.h:
3682         (JSC::UnlinkedInstruction::UnlinkedInstruction):
3683         * bytecompiler/BytecodeGenerator.cpp:
3684         (JSC::BytecodeGenerator::emitPutById):
3685         (JSC::BytecodeGenerator::emitDirectPutById):
3686         * dfg/DFGByteCodeParser.cpp:
3687         (JSC::DFG::ByteCodeParser::parseBlock):
3688         * dfg/DFGCapabilities.cpp:
3689         (JSC::DFG::capabilityLevel):
3690         * jit/JIT.cpp:
3691         (JSC::JIT::privateCompileMainPass):
3692         (JSC::JIT::privateCompileSlowCases):
3693         * jit/JITPropertyAccess.cpp:
3694         (JSC::JIT::emit_op_put_by_id):
3695         * jit/JITPropertyAccess32_64.cpp:
3696         (JSC::JIT::emit_op_put_by_id):
3697         * llint/LLIntSlowPaths.cpp:
3698         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3699         * llint/LowLevelInterpreter32_64.asm:
3700         * llint/LowLevelInterpreter64.asm:
3701
3702 2015-09-14  Commit Queue  <commit-queue@webkit.org>
3703
3704         Unreviewed, rolling out r189751, r189752, and r189754.
3705         https://bugs.webkit.org/show_bug.cgi?id=149143
3706
3707         caused crashes everywhere (Requested by alexchristensen on
3708         #webkit).
3709
3710         Reverted changesets:
3711
3712         "LLInt get/put inline caches shouldn't use tons of opcodes"
3713         https://bugs.webkit.org/show_bug.cgi?id=149106
3714         http://trac.webkit.org/changeset/189751
3715
3716         "Unreviewed, fix non-x86 LLInt build."
3717         http://trac.webkit.org/changeset/189752
3718
3719         "Unreviewed, really fix non-x86 LLInt build without also
3720         breaking everything else."
3721         http://trac.webkit.org/changeset/189754
3722
3723 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
3724
3725         Unreviewed, really fix non-x86 LLInt build without also breaking everything else.
3726
3727         * llint/LowLevelInterpreter64.asm:
3728
3729 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
3730
3731         Unreviewed, fix non-x86 LLInt build.
3732
3733         * llint/LowLevelInterpreter64.asm:
3734
3735 2015-09-13  Filip Pizlo  <fpizlo@apple.com>
3736
3737         LLInt get/put inline caches shouldn't use tons of opcodes
3738         https://bugs.webkit.org/show_bug.cgi?id=149106
3739
3740         Reviewed by Geoffrey Garen.
3741
3742         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
3743         example, instead of having get_by_id branch on the kind of offset (inline or
3744         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
3745         But the problem with this approach is that it doesn't scale. In the property type
3746         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
3747         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
3748         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
3749         checks, we'd have 6 * 11 = 66 variants of put_by_id).
3750
3751         So, this patch completely changes the strategy to mostly using branching inside the
3752         opcode implementation. It's unlikely to have a performance effect. For example, the long
3753         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
3754         and yet nobody noticed. The regression was because the inline cache was in terms of the
3755         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
3756         didn't notice that, then we probably won't notice a couple new branches. (Also, this
3757         patch fixes that regression - the code no longer does such lookups except in the one
3758         unavoidable case in put_by_id transition chain checking.)
3759
3760         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
3761         this flags field to encode the desired type check in bug 148610.
3762
3763         This patch has no effect on performance according to run-jsc-benchmarks.
3764
3765         * CMakeLists.txt:
3766         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3767         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3768         * JavaScriptCore.xcodeproj/project.pbxproj:
3769         * bytecode/BytecodeList.json:
3770         * bytecode/BytecodeUseDef.h:
3771         (JSC::computeUsesForBytecodeOffset):
3772         (JSC::computeDefsForBytecodeOffset):
3773         * bytecode/CodeBlock.cpp:
3774         (JSC::CodeBlock::printGetByIdOp):
3775         (JSC::CodeBlock::printGetByIdCacheStatus):
3776         (JSC::CodeBlock::printPutByIdCacheStatus):
3777         (JSC::CodeBlock::dumpBytecode):
3778         (JSC::CodeBlock::CodeBlock):
3779         (JSC::CodeBlock::propagateTransitions):
3780         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3781         * bytecode/CodeBlock.h:
3782         * bytecode/GetByIdStatus.cpp:
3783         (JSC::GetByIdStatus::computeFromLLInt):
3784         * bytecode/Instruction.h:
3785         (JSC::Instruction::Instruction):
3786         * bytecode/PutByIdFlags.cpp: Added.
3787         (WTF::printInternal):
3788         * bytecode/PutByIdFlags.h: Added.
3789         * bytecode/PutByIdStatus.cpp:
3790         (JSC::PutByIdStatus::computeFromLLInt):
3791         * bytecode/UnlinkedCodeBlock.h:
3792         (JSC::UnlinkedInstruction::UnlinkedInstruction):
3793         * bytecompiler/BytecodeGenerator.cpp:
3794         (JSC::BytecodeGenerator::emitPutById):
3795         (JSC::BytecodeGenerator::emitDirectPutById):
3796         * dfg/DFGAbstractInterpreterInlines.h:
3797         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3798         * dfg/DFGByteCodeParser.cpp:
3799         (JSC::DFG::ByteCodeParser::parseBlock):
3800         * dfg/DFGCapabilities.cpp:
3801         (JSC::DFG::capabilityLevel):
3802         * jit/JIT.cpp:
3803         (JSC::JIT::privateCompileMainPass):
3804         (JSC::JIT::privateCompileSlowCases):
3805         * jit/JITPropertyAccess.cpp:
3806         (JSC::JIT::emit_op_put_by_id):
3807         * jit/JITPropertyAccess32_64.cpp:
3808         (JSC::JIT::emit_op_put_by_id):
3809         * llint/LLIntSlowPaths.cpp:
3810         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3811         * llint/LowLevelInterpreter32_64.asm:
3812         * llint/LowLevelInterpreter64.asm:
3813
3814 2015-09-14  Alex Christensen  <achristensen@webkit.org>
3815
3816         Progress towards CMake on Mac.
3817         https://bugs.webkit.org/show_bug.cgi?id=149123
3818
3819         Reviewed by Chris Dumez.
3820
3821         * CMakeLists.txt:
3822         Make forwarding headers for the replay subdirectory.
3823         * PlatformMac.cmake:
3824         Make forwarding headers for the generated inspector headers. 
3825         They should eventually either be packaged correctly with JavaScriptCore headers and included correctly.
3826
3827 2015-09-14  Yusuke Suzuki  <utatane.tea@gmail.com>
3828
3829         [ES6] Cache the resolution result in JSModuleRecord
3830         https://bugs.webkit.org/show_bug.cgi?id=148896
3831
3832         Reviewed by Saam Barati.
3833
3834         The resolveExport operation is frequently called. For example,
3835         1. When instantiating the module environment, we call it for each exported name and imported
3836            name.
3837         2. When linking the imported module environment to the code block, we call it to resolve the
3838            resolution.
3839         3. When looking up the property from the namespace object, we call it to look up the original
3840            module for the imported binding.
3841         4. When creating the namespace object, we need to collect all the exported names from the module
3842            and need to resolve them by calling resolveExport.
3843
3844         However, resolveExport takes some cost. It traces the imported modules and resolves the reference
3845         queried by the original module.
3846
3847         The resolveExport operation is pure function; given a module record and an export name,
3848         it always returns the same result. So we cache resolution results in the module record to avoid
3849         repeated resolveExport calls with the same arguments.
3850         Here, we only cache the correctly resolved references, since,
3851         1. We rarely looked up the non-correctly-resolved ones. In the linking phase, attempting to
3852            resolve non-correctly-resolved ones throws a syntax error. So only namespace object creation
3853            phase does it in a syntax valid script.
3854         2. This strategy limits the size of the cache map. The number of the correctly exported bindings
3855            is defined by the modules' code. So the size does not become infinitely large.
3856
3857         Currently, the all modules cannot be linked twice. For example,
3858
3859           graph 1
3860
3861           -> (A) -> (B)
3862
3863           graph 2
3864
3865           -> (C) -> (A) -> (B)
3866
3867         We cannot test the behavior now because when executing the graph 2, (A) and (B) are already linked,
3868         it raises an error in the current loader spec. But it should be allowed[1] since it will occur when
3869         there is multiple module tag in WebCore.
3870
3871         [1]: https://github.com/whatwg/loader/issues/41
3872
3873         * runtime/JSModuleRecord.cpp:
3874         (JSC::JSModuleRecord::ResolveQuery::Hash::hash):
3875         (JSC::JSModuleRecord::ResolveQuery::Hash::equal):
3876         (JSC::JSModuleRecord::cacheResolution):
3877         (JSC::ResolveQueryHash::hash): Deleted.
3878         (JSC::ResolveQueryHash::equal): Deleted.
3879         (JSC::resolveExportLoop): Deleted.
3880         * runtime/JSModuleRecord.h:
3881         * tests/modules/caching-should-not-make-ambiguous.js: Added.
3882         * tests/modules/caching-should-not-make-ambiguous/A.js: Added.
3883         * tests/modules/caching-should-not-make-ambiguous/B.js: Added.
3884         * tests/modules/caching-should-not-make-ambiguous/C.js: Added.
3885         * tests/modules/caching-should-not-make-ambiguous/D.js: Added.
3886         * tests/modules/caching-should-not-make-ambiguous/main.js: Added.
3887         * tests/modules/different-view.js: Added.
3888         (from.string_appeared_here.shouldThrow):
3889         * tests/modules/different-view/A.js: Added.