Get rid of forward exit on DoubleAsInt32
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2013-12-10  Filip Pizlo  <fpizlo@apple.com>
2
3         Get rid of forward exit on DoubleAsInt32
4         https://bugs.webkit.org/show_bug.cgi?id=125552
5
6         Reviewed by Oliver Hunt.
7         
8         The forward exit was just there so that we wouldn't have to keep the inputs alive up to
9         the DoubleAsInt32. That's dumb. Forward exits are a complicated piece of machinery and
10         we shouldn't have it just for a bit of liveness micro-optimization.
11         
12         Also add a bunch of machinery to test this case on X86.
13
14         * assembler/AbstractMacroAssembler.h:
15         (JSC::optimizeForARMv7s):
16         (JSC::optimizeForARM64):
17         (JSC::optimizeForX86):
18         * dfg/DFGFixupPhase.cpp:
19         (JSC::DFG::FixupPhase::fixupNode):
20         * dfg/DFGNodeType.h:
21         * dfg/DFGSpeculativeJIT.cpp:
22         (JSC::DFG::SpeculativeJIT::compileDoubleAsInt32):
23         * runtime/Options.h:
24         * tests/stress/double-as-int32.js: Added.
25         (foo):
26         (test):
27
28 2013-12-10  Filip Pizlo  <fpizlo@apple.com>
29
30         Simplify CSE's treatment of NodeRelevantToOSR
31         https://bugs.webkit.org/show_bug.cgi?id=125538
32
33         Reviewed by Oliver Hunt.
34         
35         Make the NodeRelevantToOSR thing obvious: if there is any MovHint on a node then the
36         node is relevant to OSR.
37
38         * dfg/DFGCSEPhase.cpp:
39         (JSC::DFG::CSEPhase::run):
40         (JSC::DFG::CSEPhase::performNodeCSE):
41         (JSC::DFG::CSEPhase::performBlockCSE):
42
43 2013-12-10  Filip Pizlo  <fpizlo@apple.com>
44
45         Get rid of forward exit in GetByVal on Uint32Array
46         https://bugs.webkit.org/show_bug.cgi?id=125543
47
48         Reviewed by Oliver Hunt.
49
50         * dfg/DFGSpeculativeJIT.cpp:
51         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
52         * ftl/FTLLowerDFGToLLVM.cpp:
53         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
54
55 2013-12-10  Balazs Kilvady  <kilvadyb@homejinni.com>
56
57         [MIPS] Redundant instructions in code generated from offlineasm.
58         https://bugs.webkit.org/show_bug.cgi?id=125528
59
60         Reviewed by Michael Saboff.
61
62         Optimize lowering of offlineasm BaseIndex Addresses.
63
64         * offlineasm/mips.rb:
65
66 2013-12-10  Oliver Hunt  <oliver@apple.com>
67
68         Reduce the mass templatizing of the JS parser
69         https://bugs.webkit.org/show_bug.cgi?id=125535
70
71         Reviewed by Michael Saboff.
72
73         The various caches we have now have removed the need for many of
74         the template vs. regular parameters.  This patch converts those
75         template parameters to regular parameters and updates the call
76         sites.  This reduces the code size of the parser by around 15%.
77
78         * parser/ASTBuilder.h:
79         (JSC::ASTBuilder::createGetterOrSetterProperty):
80         (JSC::ASTBuilder::createProperty):
81         * parser/Parser.cpp:
82         (JSC::::parseInner):
83         (JSC::::parseSourceElements):
84         (JSC::::parseVarDeclarationList):
85         (JSC::::createBindingPattern):
86         (JSC::::tryParseDeconstructionPatternExpression):
87         (JSC::::parseDeconstructionPattern):
88         (JSC::::parseSwitchClauses):
89         (JSC::::parseSwitchDefaultClause):
90         (JSC::::parseBlockStatement):
91         (JSC::::parseFormalParameters):
92         (JSC::::parseFunctionInfo):
93         (JSC::::parseFunctionDeclaration):
94         (JSC::::parseProperty):
95         (JSC::::parseObjectLiteral):
96         (JSC::::parseStrictObjectLiteral):
97         (JSC::::parseMemberExpression):
98         * parser/Parser.h:
99         * parser/SyntaxChecker.h:
100         (JSC::SyntaxChecker::createProperty):
101         (JSC::SyntaxChecker::createGetterOrSetterProperty):
102
103 2013-12-10  Mark Hahnenberg  <mhahnenberg@apple.com>
104
105         ASSERT !heap.vm()->isInitializingObject() when finishing DFG compilation at beginning of GC
106         https://bugs.webkit.org/show_bug.cgi?id=125472
107
108         Reviewed by Geoff Garen.
109
110         This patch makes it look like it's okay to allocate so that the DFG plan finalization stuff 
111         can do what it needs to do. We already expected that we might do allocation during plan 
112         finalization and we increased the deferral depth to handle this, but we need to fix this other 
113         ASSERT stuff too.
114
115         * GNUmakefile.list.am:
116         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
117         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
118         * JavaScriptCore.xcodeproj/project.pbxproj:
119         * heap/Heap.cpp:
120         (JSC::Heap::collect):
121         * heap/Heap.h:
122         * heap/RecursiveAllocationScope.h: Added.
123         (JSC::RecursiveAllocationScope::RecursiveAllocationScope):
124         (JSC::RecursiveAllocationScope::~RecursiveAllocationScope):
125         * runtime/VM.h:
126
127 2013-12-09  Filip Pizlo  <fpizlo@apple.com>
128
129         Impose and enforce some basic rules of sanity for where Phi functions are allowed to occur and where their (optional) corresponding MovHints can be
130         https://bugs.webkit.org/show_bug.cgi?id=125480
131
132         Reviewed by Geoffrey Garen.
133         
134         Previously, if you wanted to insert some speculation right after where a value was
135         produced, you'd get super confused if that value was produced by a Phi node.  You can't
136         necessarily insert speculations after a Phi node because Phi nodes appear in this
137         special sequence of Phis and MovHints that establish the OSR exit state for a block.
138         So, you'd probably want to search for the next place where it's safe to insert things.
139         We already do this "search for beginning of next bytecode instruction" search by
140         looking at the next node that has a different CodeOrigin.  But this would be hard for a
141         Phi because those Phis and MovHints have basically random CodeOrigins and they can all
142         have different CodeOrigins.
143
144         This change imposes some sanity for this situation:
145
146         - Phis must have unset CodeOrigins.
147
148         - In each basic block, all nodes that have unset CodeOrigins must come before all nodes
149           that have set CodeOrigins.
150
151         This all ends up working out just great because prior to this change we didn't have a 
152         use for unset CodeOrigins.  I think it's appropriate to make "unset CodeOrigin" mean
153         that we're in the prologue of a basic block.
154
155         It's interesting what this means for block merging, which we don't yet do in SSA.
156         Consider merging the edge A->B.  One possibility is that the block merger is now
157         required to clean up Phi/Upsilons, and reascribe the MovHints to have the CodeOrigin of
158         the A's block terminal.  But an answer that might be better is that the originless
159         nodes at the top of the B are just given the origin of the terminal and we keep the
160         Phis.  That would require changing the above rules.  We'll see how it goes, and what we
161         end up picking...
162
163         Overall, this special-things-at-the-top rule is analogous to what other SSA-based
164         compilers do.  For example, LLVM has rules mandating that Phis appear at the top of a
165         block.
166
167         * bytecode/CodeOrigin.cpp:
168         (JSC::CodeOrigin::dump):
169         * dfg/DFGOSRExitBase.h:
170         (JSC::DFG::OSRExitBase::OSRExitBase):
171         * dfg/DFGSSAConversionPhase.cpp:
172         (JSC::DFG::SSAConversionPhase::run):
173         * dfg/DFGValidate.cpp:
174         (JSC::DFG::Validate::validate):
175         (JSC::DFG::Validate::validateSSA):
176
177 2013-12-08  Filip Pizlo  <fpizlo@apple.com>
178
179         Reveal array bounds checks in DFG IR
180         https://bugs.webkit.org/show_bug.cgi?id=125253
181
182         Reviewed by Oliver Hunt and Mark Hahnenberg.
183         
184         In SSA mode, this reveals array bounds checks and the load of array length in DFG IR,
185         making this a candidate for LICM.
186
187         This also fixes a long-standing performance bug where the JSObject slow paths would
188         always create contiguous storage, rather than type-specialized storage, when doing a
189         "storage creating" storage, like:
190         
191             var o = {};
192             o[0] = 42;
193
194         * CMakeLists.txt:
195         * GNUmakefile.list.am:
196         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
197         * JavaScriptCore.xcodeproj/project.pbxproj:
198         * bytecode/ExitKind.cpp:
199         (JSC::exitKindToString):
200         (JSC::exitKindIsCountable):
201         * bytecode/ExitKind.h:
202         * dfg/DFGAbstractInterpreterInlines.h:
203         (JSC::DFG::::executeEffects):
204         * dfg/DFGArrayMode.cpp:
205         (JSC::DFG::permitsBoundsCheckLowering):
206         (JSC::DFG::ArrayMode::permitsBoundsCheckLowering):
207         * dfg/DFGArrayMode.h:
208         (JSC::DFG::ArrayMode::lengthNeedsStorage):
209         * dfg/DFGClobberize.h:
210         (JSC::DFG::clobberize):
211         * dfg/DFGConstantFoldingPhase.cpp:
212         (JSC::DFG::ConstantFoldingPhase::foldConstants):
213         * dfg/DFGFixupPhase.cpp:
214         (JSC::DFG::FixupPhase::fixupNode):
215         * dfg/DFGNodeType.h:
216         * dfg/DFGPlan.cpp:
217         (JSC::DFG::Plan::compileInThreadImpl):
218         * dfg/DFGPredictionPropagationPhase.cpp:
219         (JSC::DFG::PredictionPropagationPhase::propagate):
220         * dfg/DFGSSALoweringPhase.cpp: Added.
221         (JSC::DFG::SSALoweringPhase::SSALoweringPhase):
222         (JSC::DFG::SSALoweringPhase::run):
223         (JSC::DFG::SSALoweringPhase::handleNode):
224         (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
225         (JSC::DFG::performSSALowering):
226         * dfg/DFGSSALoweringPhase.h: Added.
227         * dfg/DFGSafeToExecute.h:
228         (JSC::DFG::safeToExecute):
229         * dfg/DFGSpeculativeJIT.cpp:
230         (JSC::DFG::SpeculativeJIT::compileDoublePutByVal):
231         * dfg/DFGSpeculativeJIT32_64.cpp:
232         (JSC::DFG::SpeculativeJIT::compileContiguousPutByVal):
233         (JSC::DFG::SpeculativeJIT::compile):
234         * dfg/DFGSpeculativeJIT64.cpp:
235         (JSC::DFG::SpeculativeJIT::compile):
236         * ftl/FTLCapabilities.cpp:
237         (JSC::FTL::canCompile):
238         * ftl/FTLLowerDFGToLLVM.cpp:
239         (JSC::FTL::LowerDFGToLLVM::compileNode):
240         (JSC::FTL::LowerDFGToLLVM::compileCheckInBounds):
241         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
242         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
243         (JSC::FTL::LowerDFGToLLVM::contiguousPutByValOutOfBounds):
244         * runtime/JSObject.cpp:
245         (JSC::JSObject::convertUndecidedForValue):
246         (JSC::JSObject::createInitialForValueAndSet):
247         (JSC::JSObject::putByIndexBeyondVectorLength):
248         (JSC::JSObject::putDirectIndexBeyondVectorLength):
249         * runtime/JSObject.h:
250         * tests/stress/float32array-out-of-bounds.js: Added.
251         (make):
252         (foo):
253         (test):
254         * tests/stress/int32-object-out-of-bounds.js: Added.
255         (make):
256         (foo):
257         (test):
258         * tests/stress/int32-out-of-bounds.js: Added.
259         (foo):
260         (test):
261
262 2013-12-09  Sam Weinig  <sam@webkit.org>
263
264         Replace use of WTF::FixedArray with std::array
265         https://bugs.webkit.org/show_bug.cgi?id=125475
266
267         Reviewed by Anders Carlsson.
268
269         * bytecode/CodeBlockHash.cpp:
270         (JSC::CodeBlockHash::dump):
271         * bytecode/Opcode.cpp:
272         (JSC::OpcodeStats::~OpcodeStats):
273         * dfg/DFGCSEPhase.cpp:
274         * ftl/FTLAbstractHeap.h:
275         * heap/MarkedSpace.h:
276         * parser/ParserArena.h:
277         * runtime/CodeCache.h:
278         * runtime/DateInstanceCache.h:
279         * runtime/JSGlobalObject.cpp:
280         (JSC::JSGlobalObject::reset):
281         * runtime/JSGlobalObject.h:
282         * runtime/JSString.h:
283         * runtime/LiteralParser.h:
284         * runtime/NumericStrings.h:
285         * runtime/RegExpCache.h:
286         * runtime/SmallStrings.h:
287
288 2013-12-09  Joseph Pecoraro  <pecoraro@apple.com>
289
290         Remove miscellaneous unnecessary build statements
291         https://bugs.webkit.org/show_bug.cgi?id=125466
292
293         Reviewed by Darin Adler.
294
295         * DerivedSources.make:
296         * JavaScriptCore.vcxproj/build-generated-files.sh:
297         * JavaScriptCore.xcodeproj/project.pbxproj:
298         * make-generated-sources.sh:
299
300 2013-12-08  Filip Pizlo  <fpizlo@apple.com>
301
302         CSE should work in SSA
303         https://bugs.webkit.org/show_bug.cgi?id=125430
304
305         Reviewed by Oliver Hunt and Mark Hahnenberg.
306
307         * dfg/DFGCSEPhase.cpp:
308         (JSC::DFG::CSEPhase::run):
309         (JSC::DFG::CSEPhase::performNodeCSE):
310         * dfg/DFGPlan.cpp:
311         (JSC::DFG::Plan::compileInThreadImpl):
312
313 2013-12-09  Joseph Pecoraro  <pecoraro@apple.com>
314
315         Remove docs/make-bytecode-docs.pl
316         https://bugs.webkit.org/show_bug.cgi?id=125462
317
318         This sript is very old and no longer outputs useful data since the
319         op code definitions have moved from Interpreter.cpp.
320
321         Reviewed by Darin Adler.
322
323         * DerivedSources.make:
324         * docs/make-bytecode-docs.pl: Removed.
325
326 2013-12-09  Julien Brianceau  <jbriance@cisco.com>
327
328         Fix sh4 LLINT build.
329         https://bugs.webkit.org/show_bug.cgi?id=125454
330
331         Reviewed by Michael Saboff.
332
333         In LLINT, sh4 backend implementation didn't handle properly conditional jumps using
334         a LabelReference instance. This patch fixes it through sh4LowerMisplacedLabels phase.
335         Also, to avoid the need of a 4th temporary gpr, this phase is triggered later in
336         getModifiedListSH4.
337
338         * offlineasm/sh4.rb:
339
340 2013-12-08  Filip Pizlo  <fpizlo@apple.com>
341
342         Add the notion of ConstantStoragePointer to DFG IR
343         https://bugs.webkit.org/show_bug.cgi?id=125395
344
345         Reviewed by Oliver Hunt.
346         
347         This pushes more typed array folding into StrengthReductionPhase, and enables CSE on
348         storage pointers. Previously, you might have separate nodes for the same storage
349         pointer and this would cause some bad register pressure in the DFG. Note that this
350         was really a theoretical problem and not, to my knowledge a practical one - so this
351         patch is basically just a clean-up.
352
353         * dfg/DFGAbstractInterpreterInlines.h:
354         (JSC::DFG::::executeEffects):
355         * dfg/DFGCSEPhase.cpp:
356         (JSC::DFG::CSEPhase::constantStoragePointerCSE):
357         (JSC::DFG::CSEPhase::performNodeCSE):
358         * dfg/DFGClobberize.h:
359         (JSC::DFG::clobberize):
360         * dfg/DFGFixupPhase.cpp:
361         (JSC::DFG::FixupPhase::fixupNode):
362         * dfg/DFGGraph.cpp:
363         (JSC::DFG::Graph::dump):
364         * dfg/DFGNode.h:
365         (JSC::DFG::Node::convertToConstantStoragePointer):
366         (JSC::DFG::Node::hasStoragePointer):
367         (JSC::DFG::Node::storagePointer):
368         * dfg/DFGNodeType.h:
369         * dfg/DFGPredictionPropagationPhase.cpp:
370         (JSC::DFG::PredictionPropagationPhase::propagate):
371         * dfg/DFGSafeToExecute.h:
372         (JSC::DFG::safeToExecute):
373         * dfg/DFGSpeculativeJIT.cpp:
374         (JSC::DFG::SpeculativeJIT::compileConstantStoragePointer):
375         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
376         * dfg/DFGSpeculativeJIT.h:
377         * dfg/DFGSpeculativeJIT32_64.cpp:
378         (JSC::DFG::SpeculativeJIT::compile):
379         * dfg/DFGSpeculativeJIT64.cpp:
380         (JSC::DFG::SpeculativeJIT::compile):
381         * dfg/DFGStrengthReductionPhase.cpp:
382         (JSC::DFG::StrengthReductionPhase::handleNode):
383         (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant):
384         (JSC::DFG::StrengthReductionPhase::prepareToFoldTypedArray):
385         * dfg/DFGWatchpointCollectionPhase.cpp:
386         (JSC::DFG::WatchpointCollectionPhase::handle):
387         * ftl/FTLLowerDFGToLLVM.cpp:
388         (JSC::FTL::LowerDFGToLLVM::compileNode):
389         (JSC::FTL::LowerDFGToLLVM::compileConstantStoragePointer):
390         (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
391
392 2013-12-08  Filip Pizlo  <fpizlo@apple.com>
393
394         FTL should support UntypedUse versions of Compare nodes
395         https://bugs.webkit.org/show_bug.cgi?id=125426
396
397         Reviewed by Oliver Hunt.
398         
399         This adds UntypedUse versions of all comparisons except CompareStrictEq, which is
400         sufficiently different that I thought I'd do it in another patch.
401         
402         This also extends our ability to abstract over comparison kind and removes a bunch of
403         copy-paste code.
404
405         * dfg/DFGSpeculativeJIT64.cpp:
406         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
407         * ftl/FTLCapabilities.cpp:
408         (JSC::FTL::canCompile):
409         * ftl/FTLIntrinsicRepository.h:
410         * ftl/FTLLowerDFGToLLVM.cpp:
411         (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
412         (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
413         (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
414         (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
415         (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
416         (JSC::FTL::LowerDFGToLLVM::compare):
417         (JSC::FTL::LowerDFGToLLVM::nonSpeculativeCompare):
418         * ftl/FTLOutput.h:
419         (JSC::FTL::Output::icmp):
420         (JSC::FTL::Output::equal):
421         (JSC::FTL::Output::notEqual):
422         (JSC::FTL::Output::above):
423         (JSC::FTL::Output::aboveOrEqual):
424         (JSC::FTL::Output::below):
425         (JSC::FTL::Output::belowOrEqual):
426         (JSC::FTL::Output::greaterThan):
427         (JSC::FTL::Output::greaterThanOrEqual):
428         (JSC::FTL::Output::lessThan):
429         (JSC::FTL::Output::lessThanOrEqual):
430         (JSC::FTL::Output::fcmp):
431         (JSC::FTL::Output::doubleEqual):
432         (JSC::FTL::Output::doubleNotEqualOrUnordered):
433         (JSC::FTL::Output::doubleLessThan):
434         (JSC::FTL::Output::doubleLessThanOrEqual):
435         (JSC::FTL::Output::doubleGreaterThan):
436         (JSC::FTL::Output::doubleGreaterThanOrEqual):
437         (JSC::FTL::Output::doubleEqualOrUnordered):
438         (JSC::FTL::Output::doubleNotEqual):
439         (JSC::FTL::Output::doubleLessThanOrUnordered):
440         (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
441         (JSC::FTL::Output::doubleGreaterThanOrUnordered):
442         (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
443         * tests/stress/untyped-equality.js: Added.
444         (foo):
445         * tests/stress/untyped-less-than.js: Added.
446         (foo):
447
448 2013-12-07  Filip Pizlo  <fpizlo@apple.com>
449
450         Fold typedArray.length if typedArray is constant
451         https://bugs.webkit.org/show_bug.cgi?id=125252
452
453         Reviewed by Sam Weinig.
454         
455         This was meant to be easy. The problem is that there was no good place for putting
456         the folding of typedArray.length to a constant. You can't quite do it in the
457         bytecode parser because at that point you don't yet know if typedArray is really
458         a typed array. You can't do it as part of constant folding because the folder
459         assumes that it can opportunistically forward-flow a constant value without changing
460         the IR; this doesn't work since we need to first change the IR to register a
461         desired watchpoint and only after that can we introduce that constant. We could have
462         done it in Fixup but that would have been awkward since Fixup's code for turning a
463         GetById of "length" into GetArrayLength is already somewhat complex. We could have
464         done it in CSE but CSE is already fairly gnarly and will probably get rewritten.
465         
466         So I introduced a new phase, called StrengthReduction. This phase should have any
467         transformations that don't requite CFA or CSE and that it would be weird to put into
468         those other phases.
469         
470         I also took the opportunity to refactor some of the other folding code.
471         
472         This also adds a test, but the test couldn't quite be a LayoutTests/js/regress so I
473         introduced the notion of JavaScriptCore/tests/stress.
474         
475         The goal of this patch isn't really to improve performance or anything like that.
476         It adds an optimization for completeness, and in doing so it unlocks a bunch of new
477         possibilities. The one that I'm most excited about is revealing array length checks
478         in DFG IR, which will allow for array bounds check hoisting and elimination.
479
480         * CMakeLists.txt:
481         * GNUmakefile.list.am:
482         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
483         * JavaScriptCore.xcodeproj/project.pbxproj:
484         * dfg/DFGAbstractInterpreterInlines.h:
485         (JSC::DFG::::executeEffects):
486         * dfg/DFGClobberize.h:
487         (JSC::DFG::clobberize):
488         * dfg/DFGFixupPhase.cpp:
489         (JSC::DFG::FixupPhase::fixupNode):
490         * dfg/DFGGraph.cpp:
491         (JSC::DFG::Graph::tryGetFoldableView):
492         (JSC::DFG::Graph::tryGetFoldableViewForChild1):
493         * dfg/DFGGraph.h:
494         * dfg/DFGNode.h:
495         (JSC::DFG::Node::hasTypedArray):
496         (JSC::DFG::Node::typedArray):
497         * dfg/DFGNodeType.h:
498         * dfg/DFGPlan.cpp:
499         (JSC::DFG::Plan::compileInThreadImpl):
500         * dfg/DFGPredictionPropagationPhase.cpp:
501         (JSC::DFG::PredictionPropagationPhase::propagate):
502         * dfg/DFGSafeToExecute.h:
503         (JSC::DFG::safeToExecute):
504         * dfg/DFGSpeculativeJIT.cpp:
505         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
506         (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage):
507         * dfg/DFGSpeculativeJIT32_64.cpp:
508         (JSC::DFG::SpeculativeJIT::compile):
509         * dfg/DFGSpeculativeJIT64.cpp:
510         (JSC::DFG::SpeculativeJIT::compile):
511         * dfg/DFGStrengthReductionPhase.cpp: Added.
512         (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
513         (JSC::DFG::StrengthReductionPhase::run):
514         (JSC::DFG::StrengthReductionPhase::handleNode):
515         (JSC::DFG::StrengthReductionPhase::foldTypedArrayPropertyToConstant):
516         (JSC::DFG::performStrengthReduction):
517         * dfg/DFGStrengthReductionPhase.h: Added.
518         * dfg/DFGWatchpointCollectionPhase.cpp:
519         (JSC::DFG::WatchpointCollectionPhase::handle):
520         * ftl/FTLCapabilities.cpp:
521         (JSC::FTL::canCompile):
522         * ftl/FTLLowerDFGToLLVM.cpp:
523         (JSC::FTL::LowerDFGToLLVM::compileNode):
524         (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
525         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
526         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
527         * jsc.cpp:
528         (GlobalObject::finishCreation):
529         (functionTransferArrayBuffer):
530         * runtime/ArrayBufferView.h:
531         * tests/stress: Added.
532         * tests/stress/fold-typed-array-properties.js: Added.
533         (foo):
534
535 2013-12-07  peavo@outlook.com  <peavo@outlook.com>
536
537         [Win][64-bit] Hitting breakpoint assembler instruction in callToJavaScript.
538         https://bugs.webkit.org/show_bug.cgi?id=125382
539
540         Reviewed by Michael Saboff.
541
542         The WinCairo results from run-javascriptcore-tests are the same as the WinCairo 32-bits results, when removing these breakpoints.
543
544         * jit/JITStubsMSVC64.asm: Remove breakpoint instructions.
545
546 2013-12-06  Filip Pizlo  <fpizlo@apple.com>
547
548         FTL should support all of Branch/LogicalNot
549         https://bugs.webkit.org/show_bug.cgi?id=125370
550
551         Reviewed by Mark Hahnenberg.
552
553         * ftl/FTLCapabilities.cpp:
554         (JSC::FTL::canCompile):
555         * ftl/FTLIntrinsicRepository.h:
556         * ftl/FTLLowerDFGToLLVM.cpp:
557         (JSC::FTL::LowerDFGToLLVM::boolify):
558
559 2013-12-06  Roger Fong <roger_fong@apple.com> and Brent Fulgham  <bfulgham@apple.com>
560
561         [Win] Support compiling with VS2013
562         https://bugs.webkit.org/show_bug.cgi?id=125353
563
564         Reviewed by Anders Carlsson.
565
566         * API/tests/testapi.c: Use C99 defines if available.
567         * jit/JITOperations.cpp: Don't attempt to define C linkage when
568         returning a C++ object.
569
570 2013-12-06  Filip Pizlo  <fpizlo@apple.com>
571
572         FTL should support generic ByVal accesses
573         https://bugs.webkit.org/show_bug.cgi?id=125368
574
575         Reviewed by Mark Hahnenberg.
576
577         * dfg/DFGGraph.h:
578         (JSC::DFG::Graph::isStrictModeFor):
579         (JSC::DFG::Graph::ecmaModeFor):
580         * ftl/FTLCapabilities.cpp:
581         (JSC::FTL::canCompile):
582         * ftl/FTLIntrinsicRepository.h:
583         * ftl/FTLLowerDFGToLLVM.cpp:
584         (JSC::FTL::LowerDFGToLLVM::compileNode):
585         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
586         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
587
588 2013-12-06  Filip Pizlo  <fpizlo@apple.com>
589
590         FTL should support hole/OOB array accesses
591         https://bugs.webkit.org/show_bug.cgi?id=118077
592
593         Reviewed by Oliver Hunt and Mark Hahnenberg.
594
595         * ftl/FTLCapabilities.cpp:
596         (JSC::FTL::canCompile):
597         * ftl/FTLIntrinsicRepository.h:
598         * ftl/FTLLowerDFGToLLVM.cpp:
599         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
600         (JSC::FTL::LowerDFGToLLVM::baseIndex):
601
602 2013-12-06  Michael Saboff  <msaboff@apple.com>
603
604         Split sizing of VarArgs frames from loading arguments for the frame
605         https://bugs.webkit.org/show_bug.cgi?id=125331
606
607         Reviewed by Filip Pizlo.
608
609         Split loadVarargs into sizeAndAllocFrameForVarargs() and loadVarargs() in
610         preparation for moving onto the C stack.  sizeAndAllocFrameForVarargs() will
611         compute the size of the callee frame and allocate it, while loadVarargs()
612         actually loads the argument values.
613
614         As part of moving onto the C stack, sizeAndAllocFrameForVarargs() will be
615         changed to a function that just computes the size.  The caller will use that
616         size to allocate the new frame on the stack before calling loadVargs() and
617         actually making the call.
618
619         * interpreter/Interpreter.cpp:
620         (JSC::sizeAndAllocFrameForVarargs):
621         (JSC::loadVarargs):
622         * interpreter/Interpreter.h:
623         * jit/JIT.h:
624         * jit/JITCall.cpp:
625         (JSC::JIT::compileLoadVarargs):
626         * jit/JITCall32_64.cpp:
627         (JSC::JIT::compileLoadVarargs):
628         * jit/JITInlines.h:
629         (JSC::JIT::callOperation):
630         * jit/JITOperations.cpp:
631         * jit/JITOperations.h:
632         * llint/LLIntSlowPaths.cpp:
633         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
634         * llint/LLIntSlowPaths.h:
635         * llint/LowLevelInterpreter.asm:
636         * llint/LowLevelInterpreter32_64.asm:
637         * llint/LowLevelInterpreter64.asm:
638         * runtime/VM.h:
639
640 2013-12-06  Filip Pizlo  <fpizlo@apple.com>
641
642         FTL should support all of ValueToInt32
643         https://bugs.webkit.org/show_bug.cgi?id=125283
644
645         Reviewed by Mark Hahnenberg.
646
647         * ftl/FTLCapabilities.cpp:
648         (JSC::FTL::canCompile):
649         * ftl/FTLLowerDFGToLLVM.cpp:
650         (JSC::FTL::LowerDFGToLLVM::compileValueToInt32):
651         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
652         (JSC::FTL::LowerDFGToLLVM::lowCell):
653         (JSC::FTL::LowerDFGToLLVM::isCell):
654
655 2013-12-06  Filip Pizlo  <fpizlo@apple.com>
656
657         FTL shouldn't have a doubleToUInt32 path
658         https://bugs.webkit.org/show_bug.cgi?id=125360
659
660         Reviewed by Mark Hahnenberg.
661         
662         This code existed because I incorrectly thought it was necessary. It's now basically
663         dead.
664
665         * ftl/FTLLowerDFGToLLVM.cpp:
666         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
667
668 2013-12-06  Laszlo Vidacs  <lac@inf.u-szeged.hu>
669
670         Define SHA1 hash size in SHA1.h and use it at various places.
671         https://bugs.webkit.org/show_bug.cgi?id=125345
672
673         Reviewed by Darin Adler.
674
675         Use SHA1::hashSize instead of local variables.
676
677         * bytecode/CodeBlockHash.cpp:
678         (JSC::CodeBlockHash::CodeBlockHash): use SHA1::hashSize
679
680 2013-12-05  Michael Saboff  <msaboff@apple.com>
681
682         REGRESSION(r160213): Crash in js/dom/JSON-parse.html
683         https://bugs.webkit.org/show_bug.cgi?id=125335
684
685         Reviewed by Mark Lam.
686
687         Changed _llint_op_catch to materialize the VM via the scope chain instead of 
688         the CodeBlock.  CallFrames always have a scope chain, but may have a null CodeBlock.
689
690         * llint/LowLevelInterpreter32_64.asm:
691         (_llint_op_catch):
692         * llint/LowLevelInterpreter64.asm:
693         (_llint_op_catch):
694
695 2013-12-05  Michael Saboff  <msaboff@apple.com>
696
697         JSC: Simplify interface between throw and catch handler
698         https://bugs.webkit.org/show_bug.cgi?id=125328
699
700         Reviewed by Geoffrey Garen.
701
702         Simplified the throw - catch interface.  The throw side is only responsible for
703         jumping to the appropriate op_catch handler or returnFromJavaScript for uncaught
704         exceptions.  The handler uses the exception values like VM.callFrameForThrow
705         as appropriate and no longer relies on the throw side putting anything in
706         registers.
707
708         * jit/CCallHelpers.h:
709         (JSC::CCallHelpers::jumpToExceptionHandler):
710         * jit/JITOpcodes.cpp:
711         (JSC::JIT::emit_op_catch):
712         * jit/JITOpcodes32_64.cpp:
713         (JSC::JIT::emit_op_catch):
714         * llint/LowLevelInterpreter32_64.asm:
715         (_llint_op_catch):
716         (_llint_throw_from_slow_path_trampoline):
717         * llint/LowLevelInterpreter64.asm:
718         (_llint_op_catch):
719         (_llint_throw_from_slow_path_trampoline):
720
721 2013-12-04  Oliver Hunt  <oliver@apple.com>
722
723         Refactor static getter function prototype to include thisValue in addition to the base object
724         https://bugs.webkit.org/show_bug.cgi?id=124461
725
726         Reviewed by Geoffrey Garen.
727
728         Add thisValue parameter to static getter prototype, and switch
729         from JSValue to EncodedJSValue for parameters and return value.
730
731         Currently none of the static getters use the thisValue, but
732         separating out the refactoring will prevent future changes
733         from getting lost in the noise of refactoring.  This means
734         that this patch does not result in any change in behaviour.
735
736         * API/JSCallbackObject.h:
737         * API/JSCallbackObjectFunctions.h:
738         (JSC::::asCallbackObject):
739         (JSC::::staticFunctionGetter):
740         (JSC::::callbackGetter):
741         * jit/JITOperations.cpp:
742         * runtime/JSActivation.cpp:
743         (JSC::JSActivation::argumentsGetter):
744         * runtime/JSActivation.h:
745         * runtime/JSFunction.cpp:
746         (JSC::JSFunction::argumentsGetter):
747         (JSC::JSFunction::callerGetter):
748         (JSC::JSFunction::lengthGetter):
749         (JSC::JSFunction::nameGetter):
750         * runtime/JSFunction.h:
751         * runtime/JSObject.h:
752         (JSC::PropertySlot::getValue):
753         * runtime/NumberConstructor.cpp:
754         (JSC::numberConstructorNaNValue):
755         (JSC::numberConstructorNegInfinity):
756         (JSC::numberConstructorPosInfinity):
757         (JSC::numberConstructorMaxValue):
758         (JSC::numberConstructorMinValue):
759         * runtime/PropertySlot.h:
760         * runtime/RegExpConstructor.cpp:
761         (JSC::asRegExpConstructor):
762         (JSC::regExpConstructorDollar1):
763         (JSC::regExpConstructorDollar2):
764         (JSC::regExpConstructorDollar3):
765         (JSC::regExpConstructorDollar4):
766         (JSC::regExpConstructorDollar5):
767         (JSC::regExpConstructorDollar6):
768         (JSC::regExpConstructorDollar7):
769         (JSC::regExpConstructorDollar8):
770         (JSC::regExpConstructorDollar9):
771         (JSC::regExpConstructorInput):
772         (JSC::regExpConstructorMultiline):
773         (JSC::regExpConstructorLastMatch):
774         (JSC::regExpConstructorLastParen):
775         (JSC::regExpConstructorLeftContext):
776         (JSC::regExpConstructorRightContext):
777         * runtime/RegExpObject.cpp:
778         (JSC::asRegExpObject):
779         (JSC::regExpObjectGlobal):
780         (JSC::regExpObjectIgnoreCase):
781         (JSC::regExpObjectMultiline):
782         (JSC::regExpObjectSource):
783
784 2013-12-04  Filip Pizlo  <fpizlo@apple.com>
785
786         FTL should use cvttsd2si directly for double-to-int32 conversions
787         https://bugs.webkit.org/show_bug.cgi?id=125275
788
789         Reviewed by Michael Saboff.
790         
791         Wow. This was an ordeal. Using cvttsd2si was actually easy, but I learned, and
792         sometimes even fixed, some interesting things:
793         
794         - The llvm.x86.sse2.cvttsd2si intrinsic can actually result in LLVM emitting a
795           vcvttsd2si. I guess the intrinsic doesn't actually imply the instruction.
796         
797         - That whole thing about branchTruncateDoubleToUint32? Yeah we don't need that. It's
798           better to use branchTruncateDoubleToInt32 instead. It has the right semantics for
799           all of its callers (err, its one-and-only caller), and it's more likely to take
800           fast path. This patch kills branchTruncateDoubleToUint32.
801         
802         - "a[i] = v; v = a[i]". Does this change v? OK, assume that 'a[i]' is a pure-ish
803           operation - like an array access with 'i' being an integer index and we're not
804           having a bad time. Now does this change v? CSE assumes that it doesn't. That's
805           wrong. If 'a' is a typed array - the most sensible and pure kind of array - then
806           this can be a truncating cast. For example 'v' could be a double and 'a' could be
807           an integer array.
808         
809         - "v1 = a[i]; v2 = a[i]". Is v1 === v2 assuming that 'a[i]' is pure-ish? The answer
810           is no. You could have a different arrayMode in each access. I know this sounds
811           weird, but with concurrent JIT that might happen.
812         
813         This patch adds tests for all of this stuff, except for the first issue (it's weird
814         but probably doesn't matter) and the last issue (it's too much of a freakshow).
815
816         * assembler/MacroAssemblerARM64.h:
817         * assembler/MacroAssemblerARMv7.h:
818         * assembler/MacroAssemblerX86Common.h:
819         * dfg/DFGCSEPhase.cpp:
820         (JSC::DFG::CSEPhase::getByValLoadElimination):
821         (JSC::DFG::CSEPhase::performNodeCSE):
822         * dfg/DFGSpeculativeJIT.cpp:
823         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
824         * ftl/FTLAbbreviations.h:
825         (JSC::FTL::vectorType):
826         (JSC::FTL::getUndef):
827         (JSC::FTL::buildInsertElement):
828         * ftl/FTLIntrinsicRepository.h:
829         * ftl/FTLLowerDFGToLLVM.cpp:
830         (JSC::FTL::LowerDFGToLLVM::doubleToInt32):
831         (JSC::FTL::LowerDFGToLLVM::doubleToUInt32):
832         (JSC::FTL::LowerDFGToLLVM::sensibleDoubleToInt32):
833         * ftl/FTLOutput.h:
834         (JSC::FTL::Output::insertElement):
835         (JSC::FTL::Output::hasSensibleDoubleToInt):
836         (JSC::FTL::Output::sensibleDoubleToInt):
837
838 2013-12-05  Commit Queue  <commit-queue@webkit.org>
839
840         Unreviewed, rolling out r160133.
841         http://trac.webkit.org/changeset/160133
842         https://bugs.webkit.org/show_bug.cgi?id=125325
843
844         broke bindings tests on all the bots (Requested by thorton on
845         #webkit).
846
847         * API/JSCallbackObject.h:
848         * API/JSCallbackObjectFunctions.h:
849         (JSC::::staticFunctionGetter):
850         (JSC::::callbackGetter):
851         * jit/JITOperations.cpp:
852         * runtime/JSActivation.cpp:
853         (JSC::JSActivation::argumentsGetter):
854         * runtime/JSActivation.h:
855         * runtime/JSFunction.cpp:
856         (JSC::JSFunction::argumentsGetter):
857         (JSC::JSFunction::callerGetter):
858         (JSC::JSFunction::lengthGetter):
859         (JSC::JSFunction::nameGetter):
860         * runtime/JSFunction.h:
861         * runtime/JSObject.h:
862         (JSC::PropertySlot::getValue):
863         * runtime/NumberConstructor.cpp:
864         (JSC::numberConstructorNaNValue):
865         (JSC::numberConstructorNegInfinity):
866         (JSC::numberConstructorPosInfinity):
867         (JSC::numberConstructorMaxValue):
868         (JSC::numberConstructorMinValue):
869         * runtime/PropertySlot.h:
870         * runtime/RegExpConstructor.cpp:
871         (JSC::regExpConstructorDollar1):
872         (JSC::regExpConstructorDollar2):
873         (JSC::regExpConstructorDollar3):
874         (JSC::regExpConstructorDollar4):
875         (JSC::regExpConstructorDollar5):
876         (JSC::regExpConstructorDollar6):
877         (JSC::regExpConstructorDollar7):
878         (JSC::regExpConstructorDollar8):
879         (JSC::regExpConstructorDollar9):
880         (JSC::regExpConstructorInput):
881         (JSC::regExpConstructorMultiline):
882         (JSC::regExpConstructorLastMatch):
883         (JSC::regExpConstructorLastParen):
884         (JSC::regExpConstructorLeftContext):
885         (JSC::regExpConstructorRightContext):
886         * runtime/RegExpObject.cpp:
887         (JSC::regExpObjectGlobal):
888         (JSC::regExpObjectIgnoreCase):
889         (JSC::regExpObjectMultiline):
890         (JSC::regExpObjectSource):
891
892 2013-12-05  Mark Lam  <mark.lam@apple.com>
893
894         Make the C Loop LLINT work with callToJavaScript.
895         https://bugs.webkit.org/show_bug.cgi?id=125294.
896
897         Reviewed by Michael Saboff.
898
899         1. Changed the C Loop LLINT to dispatch to an Executable via its JITCode
900            instance which is consistent with how the ASM LLINT works.
901         2. Changed CLoop::execute() to take an Opcode instead of an OpcodeID.
902            This makes it play nice with the use of JITCode for dispatching.
903         3. Introduce a callToJavaScript and callToNativeFunction for the C Loop
904            LLINT. These will call JSStack::pushFrame() and popFrame() to setup
905            and teardown the CallFrame.
906         4. Also introduced a C Loop returnFromJavaScript which is just a
907            replacement for ctiOpThrowNotCaught which had the same function.
908         5. Remove a lot of #if ENABLE(LLINT_C_LOOP) code now that the dispatch
909            mechanism is consistent.
910
911         This patch has been tested with both configurations of COMPUTED_GOTOs
912         on and off.
913
914         * interpreter/CachedCall.h:
915         (JSC::CachedCall::CachedCall):
916         (JSC::CachedCall::call):
917         (JSC::CachedCall::setArgument):
918         * interpreter/CallFrameClosure.h:
919         (JSC::CallFrameClosure::setThis):
920         (JSC::CallFrameClosure::setArgument):
921         (JSC::CallFrameClosure::resetCallFrame):
922         * interpreter/Interpreter.cpp:
923         (JSC::Interpreter::execute):
924         (JSC::Interpreter::executeCall):
925         (JSC::Interpreter::executeConstruct):
926         (JSC::Interpreter::prepareForRepeatCall):
927         * interpreter/Interpreter.h:
928         * interpreter/JSStack.h:
929         * interpreter/JSStackInlines.h:
930         (JSC::JSStack::pushFrame):
931         * interpreter/ProtoCallFrame.h:
932         (JSC::ProtoCallFrame::scope):
933         (JSC::ProtoCallFrame::callee):
934         (JSC::ProtoCallFrame::thisValue):
935         (JSC::ProtoCallFrame::argument):
936         (JSC::ProtoCallFrame::setArgument):
937         * jit/JITCode.cpp:
938         (JSC::JITCode::execute):
939         * jit/JITCode.h:
940         * jit/JITExceptions.cpp:
941         (JSC::genericUnwind):
942         * llint/LLIntCLoop.cpp:
943         (JSC::LLInt::CLoop::initialize):
944         * llint/LLIntCLoop.h:
945         * llint/LLIntEntrypoint.cpp:
946         (JSC::LLInt::setFunctionEntrypoint):
947         (JSC::LLInt::setEvalEntrypoint):
948         (JSC::LLInt::setProgramEntrypoint):
949         - Inverted the check for vm.canUseJIT(). This allows the JIT case to be
950           #if'd out nicely when building the C Loop LLINT.
951         * llint/LLIntOpcode.h:
952         * llint/LLIntThunks.cpp:
953         (JSC::doCallToJavaScript):
954         (JSC::executeJS):
955         (JSC::callToJavaScript):
956         (JSC::executeNative):
957         (JSC::callToNativeFunction):
958         * llint/LLIntThunks.h:
959         * llint/LowLevelInterpreter.cpp:
960         (JSC::CLoop::execute):
961         * runtime/Executable.h:
962         (JSC::ExecutableBase::offsetOfNumParametersFor):
963         (JSC::ExecutableBase::hostCodeEntryFor):
964         (JSC::ExecutableBase::jsCodeEntryFor):
965         (JSC::ExecutableBase::jsCodeWithArityCheckEntryFor):
966         (JSC::NativeExecutable::create):
967         (JSC::NativeExecutable::finishCreation):
968         (JSC::ProgramExecutable::generatedJITCode):
969         * runtime/JSArray.cpp:
970         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key):
971         * runtime/StringPrototype.cpp:
972         (JSC::replaceUsingRegExpSearch):
973         * runtime/VM.cpp:
974         (JSC::VM::getHostFunction):
975
976 2013-12-05  Laszlo Vidacs  <lac@inf.u-szeged.hu>
977
978         Fix JavaScriptCore build if cloop is enabled after r160094
979         https://bugs.webkit.org/show_bug.cgi?id=125292
980
981         Reviewed by Michael Saboff.
982
983         Move ProtoCallFrame outside the JIT guard.
984
985         * jit/JITCode.h:
986
987 2013-12-04  Filip Pizlo  <fpizlo@apple.com>
988
989         Fold constant typed arrays
990         https://bugs.webkit.org/show_bug.cgi?id=125205
991
992         Reviewed by Oliver Hunt and Mark Hahnenberg.
993         
994         If by some other mechanism we have a typed array access on a compile-time constant
995         typed array pointer, then fold:
996         
997         - Array bounds checks. Specifically, fold the load of length.
998         
999         - Loading the vector.
1000         
1001         This needs to install a watchpoint on the array itself because of the possibility of
1002         neutering. Neutering is ridiculous. We do this without bloating the size of
1003         ArrayBuffer or JSArrayBufferView in the common case (i.e. the case where you
1004         allocated an array that didn't end up becoming a compile-time constant). To install
1005         the watchpoint, we slowDownAndWasteMemory and then create an incoming reference to
1006         the ArrayBuffer, where that incoming reference is from a watchpoint object. The
1007         ArrayBuffer already knows about such incoming references and can fire the
1008         watchpoints that way.
1009         
1010         * CMakeLists.txt:
1011         * GNUmakefile.list.am:
1012         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1013         * JavaScriptCore.xcodeproj/project.pbxproj:
1014         * dfg/DFGDesiredWatchpoints.cpp:
1015         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
1016         (JSC::DFG::DesiredWatchpoints::addLazily):
1017         * dfg/DFGDesiredWatchpoints.h:
1018         (JSC::DFG::GenericSetAdaptor::add):
1019         (JSC::DFG::GenericSetAdaptor::hasBeenInvalidated):
1020         (JSC::DFG::ArrayBufferViewWatchpointAdaptor::hasBeenInvalidated):
1021         (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
1022         (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
1023         (JSC::DFG::GenericDesiredWatchpoints::isStillValid):
1024         (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
1025         (JSC::DFG::DesiredWatchpoints::isStillValid):
1026         (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState):
1027         (JSC::DFG::DesiredWatchpoints::isValidOrMixed):
1028         * dfg/DFGGraph.cpp:
1029         (JSC::DFG::Graph::tryGetFoldableView):
1030         * dfg/DFGGraph.h:
1031         * dfg/DFGSpeculativeJIT.cpp:
1032         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayOutOfBounds):
1033         (JSC::DFG::SpeculativeJIT::emitTypedArrayBoundsCheck):
1034         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
1035         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
1036         (JSC::DFG::SpeculativeJIT::compileGetByValOnFloatTypedArray):
1037         (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
1038         (JSC::DFG::SpeculativeJIT::compileConstantIndexedPropertyStorage):
1039         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
1040         * dfg/DFGSpeculativeJIT.h:
1041         * dfg/DFGWatchpointCollectionPhase.cpp:
1042         (JSC::DFG::WatchpointCollectionPhase::handle):
1043         (JSC::DFG::WatchpointCollectionPhase::addLazily):
1044         * ftl/FTLLowerDFGToLLVM.cpp:
1045         (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
1046         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
1047         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
1048         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
1049         * runtime/ArrayBuffer.cpp:
1050         (JSC::ArrayBuffer::transfer):
1051         * runtime/ArrayBufferNeuteringWatchpoint.cpp: Added.
1052         (JSC::ArrayBufferNeuteringWatchpoint::ArrayBufferNeuteringWatchpoint):
1053         (JSC::ArrayBufferNeuteringWatchpoint::~ArrayBufferNeuteringWatchpoint):
1054         (JSC::ArrayBufferNeuteringWatchpoint::finishCreation):
1055         (JSC::ArrayBufferNeuteringWatchpoint::destroy):
1056         (JSC::ArrayBufferNeuteringWatchpoint::create):
1057         (JSC::ArrayBufferNeuteringWatchpoint::createStructure):
1058         * runtime/ArrayBufferNeuteringWatchpoint.h: Added.
1059         (JSC::ArrayBufferNeuteringWatchpoint::set):
1060         * runtime/VM.cpp:
1061         (JSC::VM::VM):
1062         * runtime/VM.h:
1063
1064 2013-12-04  Commit Queue  <commit-queue@webkit.org>
1065
1066         Unreviewed, rolling out r160116.
1067         http://trac.webkit.org/changeset/160116
1068         https://bugs.webkit.org/show_bug.cgi?id=125264
1069
1070         Change doesn't work as intended. See bug comments for details.
1071         (Requested by bfulgham on #webkit).
1072
1073         * runtime/InitializeThreading.cpp:
1074         (JSC::initializeThreading):
1075
1076 2013-12-04  Oliver Hunt  <oliver@apple.com>
1077
1078         Refactor static getter function prototype to include thisValue in addition to the base object
1079         https://bugs.webkit.org/show_bug.cgi?id=124461
1080
1081         Reviewed by Geoffrey Garen.
1082
1083         Add thisValue parameter to static getter prototype, and switch
1084         from JSValue to EncodedJSValue for parameters and return value.
1085
1086         Currently none of the static getters use the thisValue, but
1087         separating out the refactoring will prevent future changes
1088         from getting lost in the noise of refactoring.  This means
1089         that this patch does not result in any change in behaviour.
1090
1091         * API/JSCallbackObject.h:
1092         * API/JSCallbackObjectFunctions.h:
1093         (JSC::::asCallbackObject):
1094         (JSC::::staticFunctionGetter):
1095         (JSC::::callbackGetter):
1096         * jit/JITOperations.cpp:
1097         * runtime/JSActivation.cpp:
1098         (JSC::JSActivation::argumentsGetter):
1099         * runtime/JSActivation.h:
1100         * runtime/JSFunction.cpp:
1101         (JSC::JSFunction::argumentsGetter):
1102         (JSC::JSFunction::callerGetter):
1103         (JSC::JSFunction::lengthGetter):
1104         (JSC::JSFunction::nameGetter):
1105         * runtime/JSFunction.h:
1106         * runtime/JSObject.h:
1107         (JSC::PropertySlot::getValue):
1108         * runtime/NumberConstructor.cpp:
1109         (JSC::numberConstructorNaNValue):
1110         (JSC::numberConstructorNegInfinity):
1111         (JSC::numberConstructorPosInfinity):
1112         (JSC::numberConstructorMaxValue):
1113         (JSC::numberConstructorMinValue):
1114         * runtime/PropertySlot.h:
1115         * runtime/RegExpConstructor.cpp:
1116         (JSC::asRegExpConstructor):
1117         (JSC::regExpConstructorDollar1):
1118         (JSC::regExpConstructorDollar2):
1119         (JSC::regExpConstructorDollar3):
1120         (JSC::regExpConstructorDollar4):
1121         (JSC::regExpConstructorDollar5):
1122         (JSC::regExpConstructorDollar6):
1123         (JSC::regExpConstructorDollar7):
1124         (JSC::regExpConstructorDollar8):
1125         (JSC::regExpConstructorDollar9):
1126         (JSC::regExpConstructorInput):
1127         (JSC::regExpConstructorMultiline):
1128         (JSC::regExpConstructorLastMatch):
1129         (JSC::regExpConstructorLastParen):
1130         (JSC::regExpConstructorLeftContext):
1131         (JSC::regExpConstructorRightContext):
1132         * runtime/RegExpObject.cpp:
1133         (JSC::asRegExpObject):
1134         (JSC::regExpObjectGlobal):
1135         (JSC::regExpObjectIgnoreCase):
1136         (JSC::regExpObjectMultiline):
1137         (JSC::regExpObjectSource):
1138
1139 2013-12-04  Daniel Bates  <dabates@apple.com>
1140
1141         [iOS] Enable Objective-C ARC when building JSC tools for iOS simulator
1142         https://bugs.webkit.org/show_bug.cgi?id=125170
1143
1144         Reviewed by Geoffrey Garen.
1145
1146         * API/tests/testapi.mm:
1147         * Configurations/ToolExecutable.xcconfig:
1148
1149 2013-12-04  peavo@outlook.com  <peavo@outlook.com>
1150
1151         Use ThreadingOnce class to encapsulate pthread_once functionality.
1152         https://bugs.webkit.org/show_bug.cgi?id=125228
1153
1154         Reviewed by Brent Fulgham.
1155
1156         * runtime/InitializeThreading.cpp:
1157         (JSC::initializeThreading):
1158
1159 2013-12-04  Mark Lam  <mark.lam@apple.com>
1160
1161         Remove unneeded semicolons.
1162         https://bugs.webkit.org/show_bug.cgi?id=125083.
1163
1164         Rubber-stamped by Filip Pizlo.
1165
1166         * debugger/Debugger.h:
1167         (JSC::Debugger::detach):
1168         (JSC::Debugger::sourceParsed):
1169         (JSC::Debugger::exception):
1170         (JSC::Debugger::atStatement):
1171         (JSC::Debugger::callEvent):
1172         (JSC::Debugger::returnEvent):
1173         (JSC::Debugger::willExecuteProgram):
1174         (JSC::Debugger::didExecuteProgram):
1175         (JSC::Debugger::didReachBreakpoint):
1176
1177 2013-12-04  Andy Estes  <aestes@apple.com>
1178
1179         [iOS] Build projects with $(ARCHS_STANDARD_32_64_BIT)
1180         https://bugs.webkit.org/show_bug.cgi?id=125236
1181
1182         Reviewed by Sam Weinig.
1183
1184         $(ARCHS_STANDARD_32_64_BIT) is what we want for both device and simulator builds.
1185
1186         * Configurations/DebugRelease.xcconfig:
1187
1188 2013-12-03  Filip Pizlo  <fpizlo@apple.com>
1189
1190         Infer constant closure variables
1191         https://bugs.webkit.org/show_bug.cgi?id=124630
1192
1193         Reviewed by Geoffrey Garen.
1194         
1195         Captured variables that are assigned once (not counting op_enter's Undefined
1196         initialization) and that are contained within a function that has thus far only been
1197         entered once are now constant folded. It's pretty awesome.
1198         
1199         This involves a watchpoint on the assignment to variables and a watchpoint on entry
1200         into the function. The former is reused from global variable constant inference and the
1201         latter is reused from one-time closure inference.
1202
1203         * GNUmakefile.list.am:
1204         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1205         * JavaScriptCore.xcodeproj/project.pbxproj:
1206         * bytecode/CodeBlock.cpp:
1207         (JSC::CodeBlock::dumpBytecode):
1208         (JSC::CodeBlock::CodeBlock):
1209         * bytecode/Instruction.h:
1210         (JSC::Instruction::Instruction):
1211         * bytecode/Opcode.h:
1212         (JSC::padOpcodeName):
1213         * bytecode/UnlinkedCodeBlock.h:
1214         (JSC::UnlinkedInstruction::UnlinkedInstruction):
1215         * bytecode/VariableWatchpointSet.h:
1216         (JSC::VariableWatchpointSet::invalidate):
1217         * bytecode/Watchpoint.h:
1218         (JSC::WatchpointSet::invalidate):
1219         * bytecompiler/BytecodeGenerator.cpp:
1220         (JSC::BytecodeGenerator::addVar):
1221         (JSC::BytecodeGenerator::BytecodeGenerator):
1222         (JSC::BytecodeGenerator::emitInitLazyRegister):
1223         (JSC::BytecodeGenerator::emitMove):
1224         (JSC::BytecodeGenerator::emitNewFunctionInternal):
1225         (JSC::BytecodeGenerator::createArgumentsIfNecessary):
1226         * bytecompiler/BytecodeGenerator.h:
1227         (JSC::BytecodeGenerator::addVar):
1228         (JSC::BytecodeGenerator::watchableVariable):
1229         * dfg/DFGByteCodeParser.cpp:
1230         (JSC::DFG::ByteCodeParser::getLocal):
1231         (JSC::DFG::ByteCodeParser::inferredConstant):
1232         (JSC::DFG::ByteCodeParser::parseBlock):
1233         (JSC::DFG::ByteCodeParser::parse):
1234         * dfg/DFGGraph.cpp:
1235         (JSC::DFG::Graph::tryGetActivation):
1236         (JSC::DFG::Graph::tryGetRegisters):
1237         * dfg/DFGGraph.h:
1238         * jit/JIT.cpp:
1239         (JSC::JIT::privateCompileMainPass):
1240         (JSC::JIT::privateCompileSlowCases):
1241         * jit/JIT.h:
1242         * jit/JITOpcodes.cpp:
1243         (JSC::JIT::emit_op_mov):
1244         (JSC::JIT::emit_op_captured_mov):
1245         (JSC::JIT::emit_op_new_captured_func):
1246         (JSC::JIT::emitSlow_op_captured_mov):
1247         * jit/JITOpcodes32_64.cpp:
1248         (JSC::JIT::emit_op_mov):
1249         (JSC::JIT::emit_op_captured_mov):
1250         * llint/LowLevelInterpreter32_64.asm:
1251         * llint/LowLevelInterpreter64.asm:
1252         * runtime/CommonSlowPaths.cpp:
1253         (JSC::SLOW_PATH_DECL):
1254         * runtime/CommonSlowPaths.h:
1255         * runtime/ConstantMode.h: Added.
1256         * runtime/JSGlobalObject.h:
1257         * runtime/JSScope.cpp:
1258         (JSC::abstractAccess):
1259         * runtime/SymbolTable.cpp:
1260         (JSC::SymbolTableEntry::prepareToWatch):
1261
1262 2013-12-04  Brent Fulgham  <bfulgham@apple.com>
1263
1264         [Win] Unreviewed project file gardening.
1265
1266         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Remove deleted files from project.
1267         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Put files in proper directory
1268         folders to match the directory structure of the source code.
1269
1270 2013-12-04  Joseph Pecoraro  <pecoraro@apple.com>
1271
1272         Unreviewed Windows Build Fix attempt after r160099.
1273
1274         * JavaScriptCore.vcxproj/copy-files.cmd:
1275
1276 2013-12-04  Julien Brianceau  <jbriance@cisco.com>
1277
1278         REGRESSION (r160094): Fix lots of crashes for sh4 architecture.
1279         https://bugs.webkit.org/show_bug.cgi?id=125227
1280
1281         Reviewed by Michael Saboff.
1282
1283         * llint/LowLevelInterpreter32_64.asm: Do not use t4 and t5 as they match a0 and a1.
1284         * offlineasm/registers.rb: Add t7, t8 and t9 in register list for sh4 port.
1285         * offlineasm/sh4.rb: Rearrange RegisterID list and add the missing ones.
1286
1287 2013-12-03  Joseph Pecoraro  <pecoraro@apple.com>
1288
1289         Web Inspector: Push Remote Inspector debugging connection management into JavaScriptCore
1290         https://bugs.webkit.org/show_bug.cgi?id=124613
1291
1292         Reviewed by Timothy Hatcher.
1293
1294         Move the ENABLE(REMOTE_INSPECTOR) remote debugger connection management
1295         into JavaScriptCore (originally from WebKit/mac). Include enhancements:
1296
1297           * allow for different types of remote debuggable targets,
1298             eventually at least a JSContext, WebView, WKView.
1299           * allow debuggables to be registered and debugged on any thread. Unlike
1300             WebViews, JSContexts may be run entirely off of the main thread.
1301           * move the remote connection (XPC connection) itself off of the main thread,
1302             it doesn't need to be on the main thread.
1303
1304         Make JSContext @class and JavaScriptCore::JSContextRef
1305         "JavaScript" Remote Debuggables.
1306
1307         * inspector/remote/RemoteInspectorDebuggable.h: Added.
1308         * inspector/remote/RemoteInspectorDebuggable.cpp: Added.
1309         (Inspector::RemoteInspectorDebuggable::RemoteInspectorDebuggable):
1310         (Inspector::RemoteInspectorDebuggable::~RemoteInspectorDebuggable):
1311         (Inspector::RemoteInspectorDebuggable::init):
1312         (Inspector::RemoteInspectorDebuggable::update):
1313         (Inspector::RemoteInspectorDebuggable::setRemoteDebuggingAllowed):
1314         (Inspector::RemoteInspectorDebuggable::info):
1315         RemoteInspectorDebuggable defines a debuggable target. As long as
1316         something creates a debuggable and is set to allow remote inspection
1317         it will be listed in remote debuggers. For the different types of
1318         debuggables (JavaScript and Web) there is different basic information
1319         that may be listed.
1320
1321         * inspector/InspectorFrontendChannel.h: Added.
1322         (Inspector::InspectorFrontendChannel::~InspectorFrontendChannel):
1323         The only thing a debuggable needs for remote debugging is an
1324         InspectorFrontendChannel a way to send messages to a remote frontend.
1325         This class provides that method, and is vended to the
1326         RemoteInspectorDebuggable when a remote connection is setup.
1327
1328         * inspector/remote/RemoteInspector.h: Added.
1329         * inspector/remote/RemoteInspector.mm: Added.
1330         Singleton, created at least when the first Debuggable is created.
1331         This class manages the list of debuggables, any connection to a
1332         remote debugger proxy (XPC service "com.apple.webinspector").
1333
1334         (Inspector::dispatchAsyncOnQueueSafeForAnyDebuggable):
1335         (Inspector::RemoteInspector::shared):
1336         (Inspector::RemoteInspector::RemoteInspector):
1337         (Inspector::RemoteInspector::nextAvailableIdentifier):
1338         (Inspector::RemoteInspector::registerDebuggable):
1339         (Inspector::RemoteInspector::unregisterDebuggable):
1340         (Inspector::RemoteInspector::updateDebuggable):
1341         Debuggable management. When debuggables are added, removed, or updated
1342         we stash a copy of the debuggable information and push an update to
1343         debuggers. Stashing a copy of the information in the RemoteInspector
1344         is a thread safe way to avoid walking over all debuggables to gather
1345         the information when it is needed.
1346
1347         (Inspector::RemoteInspector::start):
1348         (Inspector::RemoteInspector::stop):
1349         Runtime API to enable / disable the feature.
1350
1351         (Inspector::RemoteInspector::listingForDebuggable):
1352         (Inspector::RemoteInspector::pushListingNow):
1353         (Inspector::RemoteInspector::pushListingSoon):
1354         Pushing a listing to remote debuggers.
1355
1356         (Inspector::RemoteInspector::sendMessageToRemoteFrontend):
1357         (Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
1358         (Inspector::RemoteInspector::xpcConnectionReceivedMessage):
1359         (Inspector::RemoteInspector::xpcConnectionFailed):
1360         (Inspector::RemoteInspector::xpcConnectionUnhandledMessage):
1361         XPC setup, send, and receive handling.
1362
1363         (Inspector::RemoteInspector::updateHasActiveDebugSession):
1364         Applications being debugged may want to know when a debug
1365         session is active. This provides that notification.
1366
1367         (Inspector::RemoteInspector::receivedSetupMessage):
1368         (Inspector::RemoteInspector::receivedDataMessage):
1369         (Inspector::RemoteInspector::receivedDidCloseMessage):
1370         (Inspector::RemoteInspector::receivedGetListingMessage):
1371         (Inspector::RemoteInspector::receivedIndicateMessage):
1372         (Inspector::RemoteInspector::receivedConnectionDiedMessage):
1373         Dispatching incoming remote debugging protocol messages.
1374         These are wrapping above the inspector protocol messages.
1375
1376         * inspector/remote/RemoteInspectorConstants.h: Added.
1377         Protocol messages and dictionary keys inside the messages.
1378
1379         (Inspector::RemoteInspectorDebuggableInfo::RemoteInspectorDebuggableInfo):
1380         * inspector/remote/RemoteInspectorDebuggableConnection.h: Added.
1381         * inspector/remote/RemoteInspectorDebuggableConnection.mm: Added.
1382         This is a connection between the RemoteInspector singleton and a RemoteInspectorDebuggable.
1383
1384         (Inspector::RemoteInspectorDebuggableConnection::RemoteInspectorDebuggableConnection):
1385         (Inspector::RemoteInspectorDebuggableConnection::~RemoteInspectorDebuggableConnection):
1386         Allow for dispatching messages on JavaScript debuggables on a dispatch_queue
1387         instead of the main queue.
1388
1389         (Inspector::RemoteInspectorDebuggableConnection::destination):
1390         (Inspector::RemoteInspectorDebuggableConnection::connectionIdentifier):
1391         Needed in the remote debugging protocol to identify the remote debugger.
1392
1393         (Inspector::RemoteInspectorDebuggableConnection::dispatchSyncOnDebuggable):
1394         (Inspector::RemoteInspectorDebuggableConnection::dispatchAsyncOnDebuggable):
1395         (Inspector::RemoteInspectorDebuggableConnection::setup):
1396         (Inspector::RemoteInspectorDebuggableConnection::closeFromDebuggable):
1397         (Inspector::RemoteInspectorDebuggableConnection::close):
1398         (Inspector::RemoteInspectorDebuggableConnection::sendMessageToBackend):
1399         (Inspector::RemoteInspectorDebuggableConnection::sendMessageToFrontend):
1400         The connection is a thin channel between the two sides that can be closed
1401         from either side, so there is some logic around multi-threaded access.
1402
1403         * inspector/remote/RemoteInspectorXPCConnection.h: Added.
1404         (Inspector::RemoteInspectorXPCConnection::Client::~Client):
1405         * inspector/remote/RemoteInspectorXPCConnection.mm: Added.
1406         (Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection):
1407         (Inspector::RemoteInspectorXPCConnection::~RemoteInspectorXPCConnection):
1408         (Inspector::RemoteInspectorXPCConnection::close):
1409         (Inspector::RemoteInspectorXPCConnection::deserializeMessage):
1410         (Inspector::RemoteInspectorXPCConnection::handleEvent):
1411         (Inspector::RemoteInspectorXPCConnection::sendMessage):
1412         This is a connection between the RemoteInspector singleton and an XPC service
1413         named "com.apple.webinspector". This handles serialization of the dictionary
1414         messages to and from the service. The receiving is done on a non-main queue.
1415
1416         * API/JSContext.h:
1417         * API/JSContext.mm:
1418         (-[JSContext name]):
1419         (-[JSContext setName:]):
1420         ObjC API to enable/disable JSContext remote inspection and give a name.
1421
1422         * API/JSContextRef.h:
1423         * API/JSContextRef.cpp:
1424         (JSGlobalContextGetName):
1425         (JSGlobalContextSetName):
1426         C API to give a JSContext a name.
1427
1428         * runtime/JSGlobalObject.cpp:
1429         (JSC::JSGlobalObject::setName):
1430         * runtime/JSGlobalObject.h:
1431         (JSC::JSGlobalObject::name):
1432         Shared handling of the APIs above.
1433
1434         * runtime/JSGlobalObjectDebuggable.cpp: Added.
1435         (JSC::JSGlobalObjectDebuggable::JSGlobalObjectDebuggable):
1436         (JSC::JSGlobalObjectDebuggable::name):
1437         (JSC::JSGlobalObjectDebuggable::connect):
1438         (JSC::JSGlobalObjectDebuggable::disconnect):
1439         (JSC::JSGlobalObjectDebuggable::dispatchMessageFromRemoteFrontend):
1440         * runtime/JSGlobalObjectDebuggable.h: Added.
1441         Stub for the actual remote debugging implementation. We will push
1442         down the appropriate WebCore/inspector peices suitable for debugging
1443         just a JavaScript context.
1444
1445         * CMakeLists.txt:
1446         * JavaScriptCore.xcodeproj/project.pbxproj:
1447         * GNUmakefile.am:
1448         * GNUmakefile.list.am:
1449         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1450         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1451         Update build files.
1452
1453 2013-12-04  Michael Saboff  <msaboff@apple.com>
1454
1455         Move the setting up of callee's callFrame from pushFrame to callToJavaScript thunk
1456         https://bugs.webkit.org/show_bug.cgi?id=123999
1457
1458         Reviewed by Filip Pizlo.
1459
1460         Changed LLInt and/or JIT enabled ports to allocate the stack frame in the
1461         callToJavaScript stub.  Added an additional stub, callToNativeFunction that
1462         allocates a stack frame in a similar way for calling native entry points
1463         that take a single ExecState* argument.  These stubs are implemented
1464         using common macros in LowLevelInterpreter{32_64,64}.asm.  There are also
1465         Windows X86 and X86-64 versions in the corresponding JitStubsXX.h.
1466         The stubs allocate and create a sentinel frame, then create the callee's
1467         frame, populating  the header and arguments from the passed in ProtoCallFrame*.
1468         It is assumed that the caller of either stub does a check for enough stack space
1469         via JSStack::entryCheck().
1470
1471         For ports using the C-Loop interpreter, the prior method for allocating stack
1472         frame and invoking functions is used, namely with JSStack::pushFrame() and
1473         ::popFrame().
1474
1475         Made spelling changes "sentinal" -> "sentinel".
1476
1477         * CMakeLists.txt:
1478         * GNUmakefile.list.am:
1479         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1480         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1481         * JavaScriptCore.xcodeproj/project.pbxproj:
1482         * interpreter/CachedCall.h:
1483         (JSC::CachedCall::CachedCall):
1484         (JSC::CachedCall::setThis):
1485         (JSC::CachedCall::setArgument):
1486         * interpreter/CallFrameClosure.h:
1487         (JSC::CallFrameClosure::resetCallFrame):
1488         * interpreter/Interpreter.cpp:
1489         (JSC::Interpreter::execute):
1490         (JSC::Interpreter::executeCall):
1491         (JSC::Interpreter::executeConstruct):
1492         (JSC::Interpreter::prepareForRepeatCall):
1493         * interpreter/Interpreter.h:
1494         * interpreter/JSStack.h:
1495         * interpreter/JSStackInlines.h:
1496         (JSC::JSStack::entryCheck):
1497         (JSC::JSStack::pushFrame):
1498         (JSC::JSStack::popFrame):
1499         * interpreter/ProtoCallFrame.cpp: Added.
1500         (JSC::ProtoCallFrame::init):
1501         * interpreter/ProtoCallFrame.h: Added.
1502         (JSC::ProtoCallFrame::codeBlock):
1503         (JSC::ProtoCallFrame::setCodeBlock):
1504         (JSC::ProtoCallFrame::setScope):
1505         (JSC::ProtoCallFrame::setCallee):
1506         (JSC::ProtoCallFrame::argumentCountIncludingThis):
1507         (JSC::ProtoCallFrame::argumentCount):
1508         (JSC::ProtoCallFrame::setArgumentCountIncludingThis):
1509         (JSC::ProtoCallFrame::setPaddedArgsCount):
1510         (JSC::ProtoCallFrame::clearCurrentVPC):
1511         (JSC::ProtoCallFrame::setThisValue):
1512         (JSC::ProtoCallFrame::setArgument):
1513         * jit/JITCode.cpp:
1514         (JSC::JITCode::execute):
1515         * jit/JITCode.h:
1516         * jit/JITOperations.cpp:
1517         * jit/JITStubs.h:
1518         * jit/JITStubsMSVC64.asm:
1519         * jit/JITStubsX86.h:
1520         * llint/LLIntOffsetsExtractor.cpp:
1521         * llint/LLIntThunks.h:
1522         * llint/LowLevelInterpreter.asm:
1523         * llint/LowLevelInterpreter32_64.asm:
1524         * llint/LowLevelInterpreter64.asm:
1525         * runtime/ArgList.h:
1526         (JSC::ArgList::data):
1527         * runtime/JSArray.cpp:
1528         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key):
1529         * runtime/StringPrototype.cpp:
1530         (JSC::replaceUsingRegExpSearch):
1531
1532 2013-12-04  László Langó  <lango@inf.u-szeged.hu>
1533
1534         Remove stdio.h from JSC files.
1535         https://bugs.webkit.org/show_bug.cgi?id=125220
1536
1537         Reviewed by Michael Saboff.
1538
1539         * interpreter/VMInspector.cpp:
1540         * jit/JITArithmetic.cpp:
1541         * jit/JITArithmetic32_64.cpp:
1542         * jit/JITCall.cpp:
1543         * jit/JITCall32_64.cpp:
1544         * jit/JITPropertyAccess.cpp:
1545         * jit/JITPropertyAccess32_64.cpp:
1546         * runtime/Completion.cpp:
1547         * runtime/IndexingType.cpp:
1548         * runtime/Lookup.h:
1549         * runtime/Operations.cpp:
1550         * runtime/Options.cpp:
1551         * runtime/RegExp.cpp:
1552
1553 2013-12-04  László Langó  <lango@inf.u-szeged.hu>
1554
1555         Avoid to add zero offset in BaseIndex.
1556         https://bugs.webkit.org/show_bug.cgi?id=125215
1557
1558         Reviewed by Michael Saboff.
1559
1560         When using cloop do not generate offsets additions for BaseIndex if the offset is zero.
1561
1562         * offlineasm/cloop.rb:
1563
1564 2013-12-04  Peter Molnar  <pmolnar.u-szeged@partner.samsung.com>
1565
1566         Fix !ENABLE(JAVASCRIPT_DEBUGGER) build.
1567         https://bugs.webkit.org/show_bug.cgi?id=125083
1568
1569         Reviewed by Mark Lam.
1570
1571         * debugger/Debugger.cpp:
1572         * debugger/Debugger.h:
1573         (JSC::Debugger::Debugger):
1574         (JSC::Debugger::needsOpDebugCallbacks):
1575         (JSC::Debugger::needsExceptionCallbacks):
1576         (JSC::Debugger::detach):
1577         (JSC::Debugger::sourceParsed):
1578         (JSC::Debugger::exception):
1579         (JSC::Debugger::atStatement):
1580         (JSC::Debugger::callEvent):
1581         (JSC::Debugger::returnEvent):
1582         (JSC::Debugger::willExecuteProgram):
1583         (JSC::Debugger::didExecuteProgram):
1584         (JSC::Debugger::didReachBreakpoint):
1585         * debugger/DebuggerPrimitives.h:
1586         * jit/JITOpcodes.cpp:
1587         (JSC::JIT::emit_op_debug):
1588         * jit/JITOpcodes32_64.cpp:
1589         (JSC::JIT::emit_op_debug):
1590         * llint/LLIntOfflineAsmConfig.h:
1591         * llint/LowLevelInterpreter.asm:
1592
1593 2013-12-03  Mark Lam  <mark.lam@apple.com>
1594
1595         testapi test crashes on Windows in WTF::Vector<wchar_t,64,WTF::UnsafeVectorOverflow>::size().
1596         https://bugs.webkit.org/show_bug.cgi?id=121972.
1597
1598         Reviewed by Brent Fulgham.
1599
1600         * interpreter/JSStack.cpp:
1601         (JSC::JSStack::~JSStack):
1602         - Reverting the change from r160004 since it's better to fix OSAllocatorWin
1603           to be consistent with OSAllocatorPosix.
1604
1605 2013-12-03  Mark Lam  <mark.lam@apple.com>
1606
1607         Fix LLINT_C_LOOP build for Win64.
1608         https://bugs.webkit.org/show_bug.cgi?id=125186.
1609
1610         Reviewed by Michael Saboff.
1611
1612         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1613         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1614         * jit/JITOperationsMSVC64.cpp: Added.
1615         (JSC::getHostCallReturnValueWithExecState):
1616         - Win64 will build JITStubMSVC64.asm even when !ENABLE(JIT). This results
1617           in a linkage error due to a missing getHostCallReturnValueWithExecState().
1618           So, we add a stub getHostCallReturnValueWithExecState() here to satisfy
1619           that linkage. This function will never be called.
1620           The alternative to providing such a stub is to make the MSVC project
1621           recognize if the JIT is enabled or not, and exclude JITStubMSVC64.asm
1622           if it's not enabled. We don't currently set ENABLE(JIT) via the MSVC
1623           project and the work to do that is too much trouble for what we're trying
1624           to achieve here. So, we're opting for this simpler workaround instead.
1625
1626         * llint/LowLevelInterpreter.asm:
1627         * llint/LowLevelInterpreter.cpp:
1628         (JSC::CLoop::execute):
1629         - Don't build callToJavaScript if we're building the C loop. Otherwise,
1630           the C loop won't build if !ENABLE(COMPUTE_GOTO_OPCODES). 
1631
1632 2013-12-03  Michael Saboff  <msaboff@apple.com>
1633
1634         ARM64: Crash in JIT code due to improper reuse of cached memory temp register
1635         https://bugs.webkit.org/show_bug.cgi?id=125181
1636
1637         Reviewed by Geoffrey Garen.
1638
1639         Changed load8() and load() to invalidate the memory temp CachedTempRegister when the
1640         destination of an absolute load is the memory temp register since the source address
1641         is also the memory temp register.  Change branch{8,32,64} of an AbsoluteAddress with
1642         a register to use the dataTempRegister as the destinate of the absolute load to
1643         reduce the chance that we need to invalidate the memory temp register cache.
1644         In the process, found and fixed an outright bug in branch8() where we'd load into
1645         the data temp register and then compare and branch on the memory temp register.
1646
1647         * assembler/MacroAssemblerARM64.h:
1648         (JSC::MacroAssemblerARM64::load8):
1649         (JSC::MacroAssemblerARM64::branch32):
1650         (JSC::MacroAssemblerARM64::branch64):
1651         (JSC::MacroAssemblerARM64::branch8):
1652         (JSC::MacroAssemblerARM64::load):
1653
1654 2013-12-03  Michael Saboff  <msaboff@apple.com>
1655
1656         jit/JITArithmetic.cpp doesn't build for non-X86 ports
1657         https://bugs.webkit.org/show_bug.cgi?id=125185
1658
1659         Rubber stamped by Mark Hahnenberg.
1660
1661         Removed unused declarations and related UNUSED_PARAM().
1662
1663         * jit/JITArithmetic.cpp:
1664         (JSC::JIT::emit_op_mod):
1665
1666 2013-12-03  Filip Pizlo  <fpizlo@apple.com>
1667
1668         ObjectAllocationProfile is racy and the DFG should be cool with that
1669         https://bugs.webkit.org/show_bug.cgi?id=125172
1670         <rdar://problem/15233487>
1671
1672         Reviewed by Mark Hahnenberg.
1673         
1674         We would previously sometimes get a null Structure because checking if the profile is non-null and loading
1675         the structure from it were two separate operations.
1676
1677         * dfg/DFGAbstractInterpreterInlines.h:
1678         (JSC::DFG::::executeEffects):
1679         * dfg/DFGAbstractValue.cpp:
1680         (JSC::DFG::AbstractValue::setFuturePossibleStructure):
1681         * dfg/DFGByteCodeParser.cpp:
1682         (JSC::DFG::ByteCodeParser::parseBlock):
1683         * runtime/JSFunction.h:
1684         (JSC::JSFunction::allocationProfile):
1685         (JSC::JSFunction::allocationStructure):
1686
1687 2013-12-03  peavo@outlook.com  <peavo@outlook.com>
1688
1689         testapi test crashes on Windows in WTF::Vector<wchar_t,64,WTF::UnsafeVectorOverflow>::size()
1690         https://bugs.webkit.org/show_bug.cgi?id=121972
1691
1692         Reviewed by Michael Saboff.
1693
1694         The reason for the crash is that the wrong memory block is decommitted.
1695         This can happen if no memory has been committed in the reserved block before the JSStack object is destroyed.
1696         In the JSStack destructor, the pointer to decommit then points to the end of the block (or the start of the next), and the decommit size is zero.
1697         If there is a block just after the block we are trying to decommit, this block will be decommitted, since Windows will decommit the whole block,
1698         if the decommit size is zero (see VirtualFree). When somebody tries to read/write to this block later, we crash.
1699
1700         * interpreter/JSStack.cpp:
1701         (JSC::JSStack::~JSStack): Don't decommit memory if nothing has been committed.
1702
1703 2013-12-03  László Langó  <lango@inf.u-szeged.hu>
1704
1705         Guard JIT include.
1706         https://bugs.webkit.org/show_bug.cgi?id=125063
1707
1708         Reviewed by Filip Pizlo.
1709
1710         * llint/LLIntThunks.cpp:
1711
1712 2013-12-03  Julien Brianceau  <jbriance@cisco.com>
1713
1714         Merge mips and arm/sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions.
1715         https://bugs.webkit.org/show_bug.cgi?id=125067
1716
1717         Reviewed by Michael Saboff.
1718
1719         * jit/JITOpcodes32_64.cpp:
1720         (JSC::JIT::privateCompileCTINativeCall):
1721         * jit/ThunkGenerators.cpp:
1722         (JSC::nativeForGenerator):
1723
1724 2013-12-02  Mark Lam  <mark.lam@apple.com>
1725
1726         Build failure when disabling JIT, YARR_JIT, and ASSEMBLER.
1727         https://bugs.webkit.org/show_bug.cgi?id=123809.
1728
1729         Reviewed by Geoffrey Garen.
1730
1731         Also fixed build when disabling the DISASSEMBLER.
1732         Added some needed #if's and some comments.
1733
1734         * assembler/LinkBuffer.cpp:
1735         (JSC::LinkBuffer::finalizeCodeWithDisassembly):
1736         * dfg/DFGDisassembler.cpp:
1737         * dfg/DFGDisassembler.h:
1738         (JSC::DFG::Disassembler::Disassembler):
1739         (JSC::DFG::Disassembler::setStartOfCode):
1740         (JSC::DFG::Disassembler::setForBlockIndex):
1741         (JSC::DFG::Disassembler::setForNode):
1742         (JSC::DFG::Disassembler::setEndOfMainPath):
1743         (JSC::DFG::Disassembler::setEndOfCode):
1744         (JSC::DFG::Disassembler::dump):
1745         (JSC::DFG::Disassembler::reportToProfiler):
1746         * disassembler/Disassembler.cpp:
1747         * disassembler/X86Disassembler.cpp:
1748         * jit/FPRInfo.h:
1749         * jit/GPRInfo.h:
1750         * jit/JITDisassembler.cpp:
1751         * jit/JITDisassembler.h:
1752         (JSC::JITDisassembler::JITDisassembler):
1753         (JSC::JITDisassembler::setStartOfCode):
1754         (JSC::JITDisassembler::setForBytecodeMainPath):
1755         (JSC::JITDisassembler::setForBytecodeSlowPath):
1756         (JSC::JITDisassembler::setEndOfSlowPath):
1757         (JSC::JITDisassembler::setEndOfCode):
1758         (JSC::JITDisassembler::dump):
1759         (JSC::JITDisassembler::reportToProfiler):
1760
1761 2013-12-02  Filip Pizlo  <fpizlo@apple.com>
1762
1763         Baseline JIT calls to CommonSlowPaths shouldn't restore the last result
1764         https://bugs.webkit.org/show_bug.cgi?id=125107
1765
1766         Reviewed by Mark Hahnenberg.
1767
1768         Just killing dead code.
1769
1770         * jit/JITArithmetic.cpp:
1771         (JSC::JIT::emitSlow_op_negate):
1772         (JSC::JIT::emitSlow_op_lshift):
1773         (JSC::JIT::emitSlow_op_rshift):
1774         (JSC::JIT::emitSlow_op_urshift):
1775         (JSC::JIT::emitSlow_op_bitand):
1776         (JSC::JIT::emitSlow_op_inc):
1777         (JSC::JIT::emitSlow_op_dec):
1778         (JSC::JIT::emitSlow_op_mod):
1779         (JSC::JIT::emit_op_mod):
1780         (JSC::JIT::compileBinaryArithOpSlowCase):
1781         (JSC::JIT::emitSlow_op_div):
1782         * jit/JITArithmetic32_64.cpp:
1783         (JSC::JIT::emitSlow_op_negate):
1784         (JSC::JIT::emitSlow_op_lshift):
1785         (JSC::JIT::emitRightShiftSlowCase):
1786         (JSC::JIT::emitSlow_op_bitand):
1787         (JSC::JIT::emitSlow_op_bitor):
1788         (JSC::JIT::emitSlow_op_bitxor):
1789         (JSC::JIT::emitSlow_op_inc):
1790         (JSC::JIT::emitSlow_op_dec):
1791         (JSC::JIT::emitSlow_op_add):
1792         (JSC::JIT::emitSlow_op_sub):
1793         (JSC::JIT::emitSlow_op_mul):
1794         (JSC::JIT::emitSlow_op_div):
1795         * jit/JITOpcodes.cpp:
1796         (JSC::JIT::emit_op_strcat):
1797         (JSC::JIT::emitSlow_op_get_callee):
1798         (JSC::JIT::emitSlow_op_create_this):
1799         (JSC::JIT::emitSlow_op_to_this):
1800         (JSC::JIT::emitSlow_op_to_primitive):
1801         (JSC::JIT::emitSlow_op_not):
1802         (JSC::JIT::emitSlow_op_bitxor):
1803         (JSC::JIT::emitSlow_op_bitor):
1804         (JSC::JIT::emitSlow_op_stricteq):
1805         (JSC::JIT::emitSlow_op_nstricteq):
1806         (JSC::JIT::emitSlow_op_to_number):
1807         * jit/JITOpcodes32_64.cpp:
1808         (JSC::JIT::emitSlow_op_to_primitive):
1809         (JSC::JIT::emitSlow_op_not):
1810         (JSC::JIT::emitSlow_op_stricteq):
1811         (JSC::JIT::emitSlow_op_nstricteq):
1812         (JSC::JIT::emitSlow_op_to_number):
1813         (JSC::JIT::emitSlow_op_get_callee):
1814         (JSC::JIT::emitSlow_op_create_this):
1815         (JSC::JIT::emitSlow_op_to_this):
1816
1817 2013-12-01  Filip Pizlo  <fpizlo@apple.com>
1818
1819         Stores to local captured variables should be intercepted
1820         https://bugs.webkit.org/show_bug.cgi?id=124883
1821
1822         Reviewed by Mark Hahnenberg.
1823         
1824         Previously, in bytecode, you could assign to a captured variable just as you would
1825         assign to any other kind of variable. This complicates closure variable constant
1826         inference because we don't have any place where we can intercept stores to captured
1827         variables in the LLInt.
1828         
1829         This patch institutes a policy that only certain instructions can store to captured
1830         variables. If you interpret those instructions and you are required to notifyWrite()
1831         then you need to check if the relevant variable is captured. Those instructions are
1832         tracked in CodeBlock.cpp's VerifyCapturedDef. The main one is simply op_captured_mov.
1833         In the future, we'll probably modify those instructions to have a pointer directly to
1834         the VariableWatchpointSet; but for now we just introduce the captured instructions as
1835         placeholders.
1836         
1837         In order to validate that the placeholders are inserted correctly, this patch improves
1838         the CodeBlock validation to be able to inspect every def in the bytecode. To do that,
1839         this patch refactors the liveness analysis' use/def calculator to be reusable; it now
1840         takes a functor for each use or def.
1841         
1842         In the process of refactoring the liveness analysis, I noticed that op_enter was
1843         claiming to def all callee registers. That's wrong; it only defs the non-temporary
1844         variables. Making that change revealed preexisting bugs in the liveness analysis, since
1845         now the validator would pick up cases where the bytecode claimed to use a temporary and
1846         the def calculator never noticed the definition (or the converse - where the bytecode
1847         was actually not using a temporary but the liveness analysis thought that it was a
1848         use). This patch fixes a few of those bugs.
1849
1850         * GNUmakefile.list.am:
1851         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1852         * JavaScriptCore.xcodeproj/project.pbxproj:
1853         * bytecode/BytecodeLivenessAnalysis.cpp:
1854         (JSC::stepOverInstruction):
1855         * bytecode/BytecodeUseDef.h: Added.
1856         (JSC::computeUsesForBytecodeOffset):
1857         (JSC::computeDefsForBytecodeOffset):
1858         * bytecode/CodeBlock.cpp:
1859         (JSC::CodeBlock::dumpBytecode):
1860         (JSC::CodeBlock::isCaptured):
1861         (JSC::CodeBlock::validate):
1862         * bytecode/CodeBlock.h:
1863         * bytecode/Opcode.h:
1864         (JSC::padOpcodeName):
1865         * bytecompiler/BytecodeGenerator.cpp:
1866         (JSC::BytecodeGenerator::BytecodeGenerator):
1867         (JSC::BytecodeGenerator::resolveCallee):
1868         (JSC::BytecodeGenerator::emitMove):
1869         (JSC::BytecodeGenerator::isCaptured):
1870         (JSC::BytecodeGenerator::local):
1871         (JSC::BytecodeGenerator::constLocal):
1872         (JSC::BytecodeGenerator::emitNewFunction):
1873         (JSC::BytecodeGenerator::emitLazyNewFunction):
1874         (JSC::BytecodeGenerator::emitNewFunctionInternal):
1875         * bytecompiler/BytecodeGenerator.h:
1876         (JSC::Local::Local):
1877         (JSC::Local::isCaptured):
1878         (JSC::Local::captureMode):
1879         (JSC::BytecodeGenerator::captureMode):
1880         (JSC::BytecodeGenerator::emitNode):
1881         (JSC::BytecodeGenerator::pushOptimisedForIn):
1882         * bytecompiler/NodesCodegen.cpp:
1883         (JSC::PostfixNode::emitResolve):
1884         (JSC::PrefixNode::emitResolve):
1885         (JSC::ReadModifyResolveNode::emitBytecode):
1886         (JSC::AssignResolveNode::emitBytecode):
1887         (JSC::ConstDeclNode::emitCodeSingle):
1888         (JSC::ForInNode::emitBytecode):
1889         * dfg/DFGByteCodeParser.cpp:
1890         (JSC::DFG::ByteCodeParser::parseBlock):
1891         * dfg/DFGCapabilities.cpp:
1892         (JSC::DFG::capabilityLevel):
1893         * jit/JIT.cpp:
1894         (JSC::JIT::privateCompileMainPass):
1895         * llint/LowLevelInterpreter32_64.asm:
1896         * llint/LowLevelInterpreter64.asm:
1897         * runtime/SymbolTable.h:
1898         (JSC::SymbolTable::isCaptured):
1899
1900 2013-12-02  Filip Pizlo  <fpizlo@apple.com>
1901
1902         Instead of watchpointing activation allocation, we should watchpoint entry into functions that have captured variables
1903         https://bugs.webkit.org/show_bug.cgi?id=125052
1904
1905         Reviewed by Mark Hahnenberg.
1906         
1907         This makes us watch function entry rather than activation creation. We only incur the
1908         costs of doing so for functions that have captured variables, and only on the first two
1909         entries into the function. This means that closure variable constant inference will
1910         naturally work even for local uses of the captured variable, like:
1911         
1912             (function(){
1913                 var blah = 42;
1914                 ... // stuff
1915                 function () { ... blah /* we can fold this to 42 */ }
1916                 ... blah // we can also fold this to 42.
1917             })();
1918         
1919         Previously, only the nested use would have been foldable.
1920
1921         * bytecode/BytecodeLivenessAnalysis.cpp:
1922         (JSC::computeUsesForBytecodeOffset):
1923         (JSC::computeDefsForBytecodeOffset):
1924         * bytecode/CodeBlock.cpp:
1925         (JSC::CodeBlock::dumpBytecode):
1926         * bytecode/Opcode.h:
1927         (JSC::padOpcodeName):
1928         * bytecode/Watchpoint.h:
1929         (JSC::WatchpointSet::touch):
1930         (JSC::InlineWatchpointSet::touch):
1931         * bytecompiler/BytecodeGenerator.cpp:
1932         (JSC::BytecodeGenerator::BytecodeGenerator):
1933         * dfg/DFGAbstractInterpreterInlines.h:
1934         (JSC::DFG::::executeEffects):
1935         * dfg/DFGByteCodeParser.cpp:
1936         (JSC::DFG::ByteCodeParser::parseBlock):
1937         * dfg/DFGCapabilities.cpp:
1938         (JSC::DFG::capabilityLevel):
1939         * dfg/DFGClobberize.h:
1940         (JSC::DFG::clobberize):
1941         * dfg/DFGFixupPhase.cpp:
1942         (JSC::DFG::FixupPhase::fixupNode):
1943         * dfg/DFGNode.h:
1944         (JSC::DFG::Node::hasSymbolTable):
1945         * dfg/DFGNodeType.h:
1946         * dfg/DFGPredictionPropagationPhase.cpp:
1947         (JSC::DFG::PredictionPropagationPhase::propagate):
1948         * dfg/DFGSafeToExecute.h:
1949         (JSC::DFG::safeToExecute):
1950         * dfg/DFGSpeculativeJIT32_64.cpp:
1951         (JSC::DFG::SpeculativeJIT::compile):
1952         * dfg/DFGSpeculativeJIT64.cpp:
1953         (JSC::DFG::SpeculativeJIT::compile):
1954         * dfg/DFGWatchpointCollectionPhase.cpp:
1955         (JSC::DFG::WatchpointCollectionPhase::handle):
1956         * ftl/FTLCapabilities.cpp:
1957         (JSC::FTL::canCompile):
1958         * ftl/FTLLowerDFGToLLVM.cpp:
1959         (JSC::FTL::LowerDFGToLLVM::compileNode):
1960         * jit/JIT.cpp:
1961         (JSC::JIT::privateCompileMainPass):
1962         * jit/JIT.h:
1963         * jit/JITOpcodes.cpp:
1964         (JSC::JIT::emit_op_touch_entry):
1965         * llint/LowLevelInterpreter.asm:
1966         * runtime/CommonSlowPaths.cpp:
1967         (JSC::SLOW_PATH_DECL):
1968         * runtime/CommonSlowPaths.h:
1969         * runtime/JSActivation.h:
1970         (JSC::JSActivation::create):
1971         * runtime/SymbolTable.cpp:
1972         (JSC::SymbolTable::SymbolTable):
1973         * runtime/SymbolTable.h:
1974
1975 2013-12-02  Nick Diego Yamane  <nick.yamane@openbossa.org>
1976
1977         [JSC] Get rid of some unused parameters in LLIntSlowPaths.cpp macros
1978         https://bugs.webkit.org/show_bug.cgi?id=125075
1979
1980         Reviewed by Michael Saboff.
1981
1982         * llint/LLIntSlowPaths.cpp:
1983         (JSC::LLInt::handleHostCall): added UNUSED_PARAM(pc).
1984         (JSC::LLInt::setUpCall): Doesn't pass 'pc' to LLINT_CALL macros.
1985         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Ditto.
1986
1987 2013-12-02  László Langó  <lango@inf.u-szeged.hu>
1988
1989         Remove stdio.h from JSC files.
1990         https://bugs.webkit.org/show_bug.cgi?id=125066
1991
1992         Reviewed by Michael Saboff.
1993
1994         Remove stdio.h, when it is not necessary to be included.
1995
1996         * bytecode/CodeBlock.cpp:
1997         * bytecode/StructureSet.h:
1998         * profiler/LegacyProfiler.cpp:
1999         * profiler/Profile.cpp:
2000         * profiler/ProfileNode.cpp:
2001         * yarr/YarrInterpreter.cpp:
2002
2003 2013-12-02  László Langó  <lango@inf.u-szeged.hu>
2004
2005         Unused include files when building without JIT.
2006         https://bugs.webkit.org/show_bug.cgi?id=125062
2007
2008         Reviewed by Michael Saboff.
2009
2010         We should organize the includes, and guard JIT methods
2011         in ValueRecovery.
2012
2013         * bytecode/ValueRecovery.cpp: Guard include files.
2014         * bytecode/ValueRecovery.h: Guard JIT methods.
2015
2016 2013-12-02  Balazs Kilvady  <kilvadyb@homejinni.com>
2017
2018         [MIPS] Small stack frame causes regressions.
2019         https://bugs.webkit.org/show_bug.cgi?id=124945
2020
2021         Reviewed by Michael Saboff.
2022
2023         Fix stack space for LLInt on MIPS.
2024
2025         * llint/LowLevelInterpreter32_64.asm:
2026
2027 2013-12-02  Brian J. Burg  <burg@cs.washington.edu>
2028
2029         jsc: implement a native readFile function
2030         https://bugs.webkit.org/show_bug.cgi?id=125059
2031
2032         Reviewed by Filip Pizlo.
2033
2034         This adds a native readFile() function to jsc, used to slurp
2035         an entire file into a JavaScript string.
2036
2037         * jsc.cpp:
2038         (GlobalObject::finishCreation): Add readFile() to globals.
2039         (functionReadFile): Added.
2040
2041 2013-12-02  László Langó  <lango@inf.u-szeged.hu>
2042
2043         JSC does not build if OPCODE_STATS is enabled.
2044         https://bugs.webkit.org/show_bug.cgi?id=125011
2045
2046         Reviewed by Filip Pizlo.
2047
2048         * bytecode/Opcode.cpp:
2049
2050 2013-11-29  Filip Pizlo  <fpizlo@apple.com>
2051
2052         Finally remove those DFG_ENABLE things
2053         https://bugs.webkit.org/show_bug.cgi?id=125025
2054
2055         Rubber stamped by Sam Weinig.
2056         
2057         This removes a bunch of unused and untested insanity.
2058
2059         * bytecode/CodeBlock.cpp:
2060         (JSC::CodeBlock::tallyFrequentExitSites):
2061         * dfg/DFGArgumentsSimplificationPhase.cpp:
2062         (JSC::DFG::ArgumentsSimplificationPhase::run):
2063         * dfg/DFGByteCodeParser.cpp:
2064         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
2065         (JSC::DFG::ByteCodeParser::getArrayModeConsideringSlowPath):
2066         (JSC::DFG::ByteCodeParser::makeSafe):
2067         (JSC::DFG::ByteCodeParser::makeDivSafe):
2068         (JSC::DFG::ByteCodeParser::handleCall):
2069         (JSC::DFG::ByteCodeParser::handleInlining):
2070         (JSC::DFG::ByteCodeParser::parseBlock):
2071         (JSC::DFG::ByteCodeParser::linkBlock):
2072         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2073         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2074         (JSC::DFG::ByteCodeParser::parse):
2075         (JSC::DFG::parse):
2076         * dfg/DFGCFGSimplificationPhase.cpp:
2077         (JSC::DFG::CFGSimplificationPhase::run):
2078         (JSC::DFG::CFGSimplificationPhase::convertToJump):
2079         (JSC::DFG::CFGSimplificationPhase::fixJettisonedPredecessors):
2080         * dfg/DFGCSEPhase.cpp:
2081         (JSC::DFG::CSEPhase::endIndexForPureCSE):
2082         (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
2083         (JSC::DFG::CSEPhase::setReplacement):
2084         (JSC::DFG::CSEPhase::eliminate):
2085         (JSC::DFG::CSEPhase::performNodeCSE):
2086         * dfg/DFGCommon.h:
2087         (JSC::DFG::verboseCompilationEnabled):
2088         (JSC::DFG::logCompilationChanges):
2089         (JSC::DFG::shouldDumpGraphAtEachPhase):
2090         * dfg/DFGConstantFoldingPhase.cpp:
2091         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2092         * dfg/DFGFixupPhase.cpp:
2093         (JSC::DFG::FixupPhase::fixupNode):
2094         (JSC::DFG::FixupPhase::injectInt32ToDoubleNode):
2095         * dfg/DFGInPlaceAbstractState.cpp:
2096         (JSC::DFG::InPlaceAbstractState::initialize):
2097         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
2098         (JSC::DFG::InPlaceAbstractState::mergeStateAtTail):
2099         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
2100         * dfg/DFGJITCompiler.cpp:
2101         (JSC::DFG::JITCompiler::compileBody):
2102         (JSC::DFG::JITCompiler::link):
2103         * dfg/DFGOSRExitCompiler.cpp:
2104         * dfg/DFGOSRExitCompiler32_64.cpp:
2105         (JSC::DFG::OSRExitCompiler::compileExit):
2106         * dfg/DFGOSRExitCompiler64.cpp:
2107         (JSC::DFG::OSRExitCompiler::compileExit):
2108         * dfg/DFGOSRExitCompilerCommon.cpp:
2109         (JSC::DFG::adjustAndJumpToTarget):
2110         * dfg/DFGPredictionInjectionPhase.cpp:
2111         (JSC::DFG::PredictionInjectionPhase::run):
2112         * dfg/DFGPredictionPropagationPhase.cpp:
2113         (JSC::DFG::PredictionPropagationPhase::run):
2114         (JSC::DFG::PredictionPropagationPhase::propagate):
2115         (JSC::DFG::PredictionPropagationPhase::propagateForward):
2116         (JSC::DFG::PredictionPropagationPhase::propagateBackward):
2117         (JSC::DFG::PredictionPropagationPhase::doRoundOfDoubleVoting):
2118         * dfg/DFGScoreBoard.h:
2119         (JSC::DFG::ScoreBoard::use):
2120         * dfg/DFGSlowPathGenerator.h:
2121         (JSC::DFG::SlowPathGenerator::generate):
2122         * dfg/DFGSpeculativeJIT.cpp:
2123         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
2124         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
2125         (JSC::DFG::SpeculativeJIT::dump):
2126         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2127         (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
2128         * dfg/DFGSpeculativeJIT.h:
2129         * dfg/DFGSpeculativeJIT32_64.cpp:
2130         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2131         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
2132         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2133         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2134         (JSC::DFG::SpeculativeJIT::compile):
2135         * dfg/DFGSpeculativeJIT64.cpp:
2136         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
2137         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
2138         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2139         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2140         (JSC::DFG::SpeculativeJIT::compile):
2141         * dfg/DFGVariableEventStream.cpp:
2142         (JSC::DFG::VariableEventStream::reconstruct):
2143         * dfg/DFGVariableEventStream.h:
2144         (JSC::DFG::VariableEventStream::appendAndLog):
2145         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2146         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2147         * jit/JIT.cpp:
2148         (JSC::JIT::privateCompile):
2149
2150 2013-11-29  Filip Pizlo  <fpizlo@apple.com>
2151
2152         FTL IC should nop-fill to make up the difference between the actual IC size and the requested patchpoint size
2153         https://bugs.webkit.org/show_bug.cgi?id=124960
2154
2155         Reviewed by Sam Weinig.
2156
2157         * assembler/LinkBuffer.h:
2158         (JSC::LinkBuffer::size):
2159         * assembler/X86Assembler.h:
2160         (JSC::X86Assembler::fillNops):
2161         * dfg/DFGDisassembler.cpp:
2162         (JSC::DFG::Disassembler::dumpHeader):
2163         * ftl/FTLCompile.cpp:
2164         (JSC::FTL::generateICFastPath):
2165         * jit/JITDisassembler.cpp:
2166         (JSC::JITDisassembler::dumpHeader):
2167
2168 2013-11-29  Julien Brianceau  <jbriance@cisco.com>
2169
2170         Use moveDoubleToInts in SpecializedThunkJIT::returnDouble for non-X86 JSVALUE32_64 ports.
2171         https://bugs.webkit.org/show_bug.cgi?id=124936
2172
2173         Reviewed by Zoltan Herczeg.
2174
2175         The moveDoubleToInts implementations in ARM, MIPS and SH4 macro assemblers do not clobber
2176         src FPRegister and are likely to be more efficient than the current generic implementation
2177         using the stack.
2178
2179         * jit/SpecializedThunkJIT.h:
2180         (JSC::SpecializedThunkJIT::returnDouble):
2181
2182 2013-11-29  Julien Brianceau  <jbriance@cisco.com>
2183
2184         Merge arm and sh4 paths in nativeForGenerator and privateCompileCTINativeCall functions.
2185         https://bugs.webkit.org/show_bug.cgi?id=124892
2186
2187         Reviewed by Zoltan Herczeg.
2188
2189         * assembler/MacroAssemblerSH4.h:
2190         (JSC::MacroAssemblerSH4::call): Pick a scratch register instead of getting it as a
2191         parameter. The sh4 port was the only one to have this call(Address, RegisterID) prototype.
2192         * jit/JITOpcodes32_64.cpp:
2193         (JSC::JIT::privateCompileCTINativeCall): Use argumentGPRx and merge arm and sh4 paths.
2194         * jit/ThunkGenerators.cpp:
2195         (JSC::nativeForGenerator): Use argumentGPRx and merge arm and sh4 paths.
2196
2197 2013-11-28  Nadav Rotem  <nrotem@apple.com>
2198
2199         Revert the X86 assembler peephole changes
2200         https://bugs.webkit.org/show_bug.cgi?id=124988
2201
2202         Reviewed by Csaba Osztrogonác.
2203
2204         * assembler/MacroAssemblerX86.h:
2205         (JSC::MacroAssemblerX86::add32):
2206         (JSC::MacroAssemblerX86::add64):
2207         (JSC::MacroAssemblerX86::or32):
2208         * assembler/MacroAssemblerX86Common.h:
2209         (JSC::MacroAssemblerX86Common::add32):
2210         (JSC::MacroAssemblerX86Common::or32):
2211         (JSC::MacroAssemblerX86Common::branchAdd32):
2212         * assembler/MacroAssemblerX86_64.h:
2213         (JSC::MacroAssemblerX86_64::add32):
2214         (JSC::MacroAssemblerX86_64::or32):
2215         (JSC::MacroAssemblerX86_64::add64):
2216         (JSC::MacroAssemblerX86_64::or64):
2217         (JSC::MacroAssemblerX86_64::xor64):
2218
2219 2013-11-28  Antti Koivisto  <antti@apple.com>
2220
2221         Remove feature: CSS variables
2222         https://bugs.webkit.org/show_bug.cgi?id=114119
2223
2224         Reviewed by Andreas Kling.
2225
2226         * Configurations/FeatureDefines.xcconfig:
2227
2228 2013-11-28  Peter Gal  <galpeter@inf.u-szeged.hu>
2229
2230         Typo fix after r159834 to fix 32 bit builds.
2231
2232         Reviewed by Csaba Osztrogonác.
2233
2234         * dfg/DFGSpeculativeJIT32_64.cpp:
2235         (JSC::DFG::SpeculativeJIT::compile):
2236
2237 2013-11-27  Nadav Rotem  <nrotem@apple.com>
2238
2239         Add a bunch of early exits and local optimizations to the x86 assembler.
2240         https://bugs.webkit.org/show_bug.cgi?id=124904
2241
2242         Reviewed by Filip Pizlo.
2243
2244         * assembler/MacroAssemblerX86.h:
2245         (JSC::MacroAssemblerX86::add32):
2246         (JSC::MacroAssemblerX86::add64):
2247         (JSC::MacroAssemblerX86::or32):
2248         * assembler/MacroAssemblerX86Common.h:
2249         (JSC::MacroAssemblerX86Common::add32):
2250         (JSC::MacroAssemblerX86Common::or32):
2251         * assembler/MacroAssemblerX86_64.h:
2252         (JSC::MacroAssemblerX86_64::add32):
2253         (JSC::MacroAssemblerX86_64::or32):
2254         (JSC::MacroAssemblerX86_64::add64):
2255         (JSC::MacroAssemblerX86_64::or64):
2256         (JSC::MacroAssemblerX86_64::xor64):
2257
2258 2013-11-27  Filip Pizlo  <fpizlo@apple.com>
2259
2260         Infer one-time scopes
2261         https://bugs.webkit.org/show_bug.cgi?id=124812
2262
2263         Reviewed by Oliver Hunt.
2264         
2265         This detects JSActivations that are created only once. The JSActivation pointer is then
2266         baked into the machine code.
2267         
2268         This takes advantage of the one-time scope inference to reduce the number of
2269         indirections needed to get to a closure variable in case where the scope is only
2270         allocated once. This isn't really a speed-up since in the common case the total number
2271         of instruction bytes needed to load the scope from the stack is about equal to the
2272         number of instruction bytes needed to materialize the absolute address of a scoped
2273         variable. But, this is a necessary prerequisite to
2274         https://bugs.webkit.org/show_bug.cgi?id=124630, so it's probably a good idea anyway.
2275
2276         * bytecode/CodeBlock.cpp:
2277         (JSC::CodeBlock::dumpBytecode):
2278         (JSC::CodeBlock::CodeBlock):
2279         (JSC::CodeBlock::finalizeUnconditionally):
2280         * bytecode/Instruction.h:
2281         * bytecode/Opcode.h:
2282         (JSC::padOpcodeName):
2283         * bytecode/Watchpoint.h:
2284         (JSC::WatchpointSet::notifyWrite):
2285         (JSC::InlineWatchpointSet::notifyWrite):
2286         * bytecompiler/BytecodeGenerator.cpp:
2287         (JSC::BytecodeGenerator::emitResolveScope):
2288         * dfg/DFGAbstractInterpreterInlines.h:
2289         (JSC::DFG::::executeEffects):
2290         * dfg/DFGByteCodeParser.cpp:
2291         (JSC::DFG::ByteCodeParser::parseBlock):
2292         * dfg/DFGCSEPhase.cpp:
2293         (JSC::DFG::CSEPhase::scopedVarLoadElimination):
2294         (JSC::DFG::CSEPhase::scopedVarStoreElimination):
2295         (JSC::DFG::CSEPhase::getLocalLoadElimination):
2296         (JSC::DFG::CSEPhase::setLocalStoreElimination):
2297         * dfg/DFGClobberize.h:
2298         (JSC::DFG::clobberize):
2299         * dfg/DFGFixupPhase.cpp:
2300         (JSC::DFG::FixupPhase::fixupNode):
2301         * dfg/DFGGraph.cpp:
2302         (JSC::DFG::Graph::tryGetRegisters):
2303         * dfg/DFGGraph.h:
2304         * dfg/DFGNode.h:
2305         (JSC::DFG::Node::varNumber):
2306         (JSC::DFG::Node::hasSymbolTable):
2307         (JSC::DFG::Node::symbolTable):
2308         * dfg/DFGNodeType.h:
2309         * dfg/DFGPredictionPropagationPhase.cpp:
2310         (JSC::DFG::PredictionPropagationPhase::propagate):
2311         * dfg/DFGSafeToExecute.h:
2312         (JSC::DFG::safeToExecute):
2313         * dfg/DFGSpeculativeJIT32_64.cpp:
2314         (JSC::DFG::SpeculativeJIT::compile):
2315         * dfg/DFGSpeculativeJIT64.cpp:
2316         (JSC::DFG::SpeculativeJIT::compile):
2317         * dfg/DFGWatchpointCollectionPhase.cpp:
2318         (JSC::DFG::WatchpointCollectionPhase::handle):
2319         * ftl/FTLCapabilities.cpp:
2320         (JSC::FTL::canCompile):
2321         * ftl/FTLLowerDFGToLLVM.cpp:
2322         (JSC::FTL::LowerDFGToLLVM::compileNode):
2323         (JSC::FTL::LowerDFGToLLVM::compileGetClosureRegisters):
2324         * llint/LowLevelInterpreter32_64.asm:
2325         * llint/LowLevelInterpreter64.asm:
2326         * runtime/JSActivation.h:
2327         (JSC::JSActivation::create):
2328         * runtime/JSScope.cpp:
2329         (JSC::abstractAccess):
2330         (JSC::JSScope::abstractResolve):
2331         * runtime/JSScope.h:
2332         (JSC::ResolveOp::ResolveOp):
2333         * runtime/JSVariableObject.h:
2334         (JSC::JSVariableObject::registers):
2335         * runtime/SymbolTable.cpp:
2336         (JSC::SymbolTable::SymbolTable):
2337         * runtime/SymbolTable.h:
2338
2339 2013-11-27  Filip Pizlo  <fpizlo@apple.com>
2340
2341         Finally fix some obvious Bartlett bugs
2342         https://bugs.webkit.org/show_bug.cgi?id=124951
2343
2344         Reviewed by Mark Hahnenberg.
2345         
2346         Sanitize the stack (i.e. zero parts of it known to be dead) at three key points:
2347         
2348         - GC.
2349         
2350         - At beginning of OSR entry.
2351         
2352         - Just as we finish preparing OSR entry. This clears those slots on the stack that
2353           could have been live in baseline but that are known to be dead in DFG.
2354         
2355         This is as much as a 2x speed-up on splay if you run it in certain modes, and run it
2356         for a long enough interval. It appears to fix all instances of the dreaded exponential
2357         heap growth that splay gets into when some stale pointer stays around.
2358         
2359         This doesn't have much of an effect on real-world programs. This bug has only ever
2360         manifested in splay and for that reason we thus far opted against fixing it. But splay
2361         is, for what it's worth, the premiere GC stress test in JavaScript - so making sure we
2362         can run it without pathologies - even when you tweak its configuration - is probably
2363         fairly important.
2364
2365         * dfg/DFGJITCompiler.h:
2366         (JSC::DFG::JITCompiler::noticeOSREntry):
2367         * dfg/DFGOSREntry.cpp:
2368         (JSC::DFG::prepareOSREntry):
2369         * dfg/DFGOSREntry.h:
2370         * heap/Heap.cpp:
2371         (JSC::Heap::markRoots):
2372         * interpreter/JSStack.cpp:
2373         (JSC::JSStack::JSStack):
2374         (JSC::JSStack::sanitizeStack):
2375         * interpreter/JSStack.h:
2376
2377 2013-11-26  Filip Pizlo  <fpizlo@apple.com>
2378
2379         Do bytecode validation as part of testing
2380         https://bugs.webkit.org/show_bug.cgi?id=124913
2381
2382         Reviewed by Oliver Hunt.
2383         
2384         Also fix some small bugs in the bytecode liveness analysis that I found by doing
2385         this validation thingy.
2386
2387         * bytecode/BytecodeLivenessAnalysis.cpp:
2388         (JSC::isValidRegisterForLiveness):
2389         (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
2390         * bytecode/CodeBlock.cpp:
2391         (JSC::CodeBlock::validate):
2392         (JSC::CodeBlock::beginValidationDidFail):
2393         (JSC::CodeBlock::endValidationDidFail):
2394         * bytecode/CodeBlock.h:
2395         * runtime/Executable.cpp:
2396         (JSC::ScriptExecutable::prepareForExecutionImpl):
2397         * runtime/Options.h:
2398
2399 2013-11-27  Andreas Kling  <akling@apple.com>
2400
2401         Structure::m_staticFunctionReified should be a single bit.
2402         <https://webkit.org/b/124912>
2403
2404         Shave 8 bytes off of JSC::Structure by jamming m_staticFunctionReified
2405         into the bitfield just above.
2406
2407         Reviewed by Antti Koivisto.
2408
2409 2013-11-27  Andreas Kling  <akling@apple.com>
2410
2411         JSActivation constructor should use NotNull placement new.
2412         <https://webkit.org/b/124909>
2413
2414         Knock a null check outta the storage initialization loop.
2415
2416         Reviewed by Antti Koivisto.
2417
2418 2013-11-26  Filip Pizlo  <fpizlo@apple.com>
2419
2420         Restructure global variable constant inference so that it could work for any kind of symbol table variable
2421         https://bugs.webkit.org/show_bug.cgi?id=124760
2422
2423         Reviewed by Oliver Hunt.
2424         
2425         This changes the way global variable constant inference works so that it can be reused
2426         for closure variable constant inference. Some of the premises that originally motivated
2427         this patch are somewhat wrong, but it led to some simplifications anyway and I suspect
2428         that we'll be able to fix those premises in the future. The main point of this patch is
2429         to make it easy to reuse global variable constant inference for closure variable
2430         constant inference, and this will be possible provided we can also either (a) infer
2431         one-shot closures (easy) or (b) infer closure variables that are always assigned prior
2432         to first use.
2433         
2434         One of the things that this patch is meant to enable is constant inference for closure
2435         variables that may be part of a multi-shot closure. Closure variables may be
2436         instantiated multiple times, like:
2437         
2438             function foo() {
2439                 var WIDTH = 45;
2440                 function bar() {
2441                     ... use WIDTH ...
2442                 }
2443                 ...
2444             }
2445         
2446         Even if foo() is called many times and WIDTH is assigned to multiple times, that
2447         doesn't change the fact that it's a constant. The goal of closure variable constant
2448         inference is to catch any case where a closure variable has been assigned at least once
2449         and its value has never changed. This patch doesn't implement that, but it does change
2450         global variable constant inference to have most of the powers needed to do that. Note
2451         that most likely we will use this functionality only to implement constant inference
2452         for one-shot closures, but the resulting machinery is still simpler than what we had
2453         before.
2454         
2455         This involves three changes:
2456         
2457             - The watchpoint object now contains the inferred value. This involves creating a
2458               new kind of watchpoint set, the VariableWatchpointSet. We will reuse this object
2459               for closure variables.
2460         
2461             - Writing to a variable that is watchpointed still involves these three states that
2462               we proceed through monotonically (Uninitialized->Initialized->Invalidated) but
2463               now, the Initialized->Invalidated state transition only happens if we change the
2464               variable's value, rather than store to the variable. Repeatedly storing the same
2465               value won't change the variable's state.
2466         
2467             - On 64-bit systems (the only systems on which we do concurrent JIT), you no longer
2468               need fancy fencing to get a consistent view of the watchpoint in the JIT. The
2469               state of the VariableWatchpointSet for the purposes of constant folding is
2470               entirely encapsulated in the VariableWatchpointSet::m_inferredValue. If that is
2471               JSValue() then you cannot fold (either because the set is uninitialized or
2472               because it's invalidated - doesn't matter which); on the other hand if the value
2473               is anything other than JSValue() then you can fold, and that's the value you fold
2474               to. Simple!
2475         
2476         This also changes the way that DFG IR deals with variable watchpoints. It's now
2477         oblivious to global variables. You install a watchpoint using VariableWatchpoint and
2478         you notify write using NotifyWrite. Easy!
2479         
2480         Note that this will requires some more tweaks because of the fact that op_enter will
2481         store Undefined into every captured variable. Hence it won't even work for one-shot
2482         closures. One-shot closures are easily fixed by introducing another state (so we'll
2483         have Uninitialized->Undefined->Initialized->Invalidated). Multi-shot closures will
2484         require static analysis. One-shot closures are clearly a higher priority.
2485
2486         * GNUmakefile.list.am:
2487         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2488         * JavaScriptCore.xcodeproj/project.pbxproj:
2489         * bytecode/Instruction.h:
2490         * bytecode/VariableWatchpointSet.h: Added.
2491         (JSC::VariableWatchpointSet::VariableWatchpointSet):
2492         (JSC::VariableWatchpointSet::~VariableWatchpointSet):
2493         (JSC::VariableWatchpointSet::inferredValue):
2494         (JSC::VariableWatchpointSet::notifyWrite):
2495         (JSC::VariableWatchpointSet::invalidate):
2496         (JSC::VariableWatchpointSet::finalizeUnconditionally):
2497         (JSC::VariableWatchpointSet::addressOfInferredValue):
2498         * bytecode/Watchpoint.h:
2499         * dfg/DFGAbstractInterpreterInlines.h:
2500         (JSC::DFG::::executeEffects):
2501         * dfg/DFGByteCodeParser.cpp:
2502         (JSC::DFG::ByteCodeParser::parseBlock):
2503         * dfg/DFGCSEPhase.cpp:
2504         (JSC::DFG::CSEPhase::performNodeCSE):
2505         * dfg/DFGClobberize.h:
2506         (JSC::DFG::clobberize):
2507         * dfg/DFGFixupPhase.cpp:
2508         (JSC::DFG::FixupPhase::fixupNode):
2509         * dfg/DFGNode.h:
2510         (JSC::DFG::Node::hasRegisterPointer):
2511         (JSC::DFG::Node::hasVariableWatchpointSet):
2512         (JSC::DFG::Node::variableWatchpointSet):
2513         * dfg/DFGNodeType.h:
2514         * dfg/DFGOperations.cpp:
2515         * dfg/DFGOperations.h:
2516         * dfg/DFGPredictionPropagationPhase.cpp:
2517         (JSC::DFG::PredictionPropagationPhase::propagate):
2518         * dfg/DFGSafeToExecute.h:
2519         (JSC::DFG::safeToExecute):
2520         * dfg/DFGSpeculativeJIT.cpp:
2521         (JSC::DFG::SpeculativeJIT::compileArithMod):
2522         * dfg/DFGSpeculativeJIT.h:
2523         (JSC::DFG::SpeculativeJIT::callOperation):
2524         * dfg/DFGSpeculativeJIT32_64.cpp:
2525         (JSC::DFG::SpeculativeJIT::compile):
2526         * dfg/DFGSpeculativeJIT64.cpp:
2527         (JSC::DFG::SpeculativeJIT::compile):
2528         * dfg/DFGWatchpointCollectionPhase.cpp:
2529         (JSC::DFG::WatchpointCollectionPhase::handle):
2530         * ftl/FTLCapabilities.cpp:
2531         (JSC::FTL::canCompile):
2532         * ftl/FTLLowerDFGToLLVM.cpp:
2533         (JSC::FTL::LowerDFGToLLVM::compileNode):
2534         (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
2535         * jit/JIT.h:
2536         * jit/JITOperations.h:
2537         * jit/JITPropertyAccess.cpp:
2538         (JSC::JIT::emitNotifyWrite):
2539         (JSC::JIT::emitPutGlobalVar):
2540         * jit/JITPropertyAccess32_64.cpp:
2541         (JSC::JIT::emitNotifyWrite):
2542         (JSC::JIT::emitPutGlobalVar):
2543         * llint/LowLevelInterpreter32_64.asm:
2544         * llint/LowLevelInterpreter64.asm:
2545         * runtime/JSGlobalObject.cpp:
2546         (JSC::JSGlobalObject::addGlobalVar):
2547         (JSC::JSGlobalObject::addFunction):
2548         * runtime/JSGlobalObject.h:
2549         * runtime/JSScope.h:
2550         (JSC::ResolveOp::ResolveOp):
2551         * runtime/JSSymbolTableObject.h:
2552         (JSC::symbolTablePut):
2553         (JSC::symbolTablePutWithAttributes):
2554         * runtime/SymbolTable.cpp:
2555         (JSC::SymbolTableEntry::inferredValue):
2556         (JSC::SymbolTableEntry::prepareToWatch):
2557         (JSC::SymbolTableEntry::addWatchpoint):
2558         (JSC::SymbolTableEntry::notifyWriteSlow):
2559         (JSC::SymbolTable::visitChildren):
2560         (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup):
2561         (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup):
2562         (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally):
2563         * runtime/SymbolTable.h:
2564         (JSC::SymbolTableEntry::watchpointSet):
2565         (JSC::SymbolTableEntry::notifyWrite):
2566
2567 2013-11-24  Filip Pizlo  <fpizlo@apple.com>
2568
2569         Create a new SymbolTable every time code is loaded so that the watchpoints don't get reused
2570         https://bugs.webkit.org/show_bug.cgi?id=124824
2571
2572         Reviewed by Oliver Hunt.
2573         
2574         This helps with one shot closure inference as well as closure variable constant
2575         inference, since without this, if code was reloaded from the cache then we would
2576         think that the first run was actually an Nth run. This would cause us to think that
2577         the watchpoint(s) should all be invalidated.
2578
2579         * bytecode/CodeBlock.cpp:
2580         (JSC::CodeBlock::CodeBlock):
2581         (JSC::CodeBlock::stronglyVisitStrongReferences):
2582         * bytecode/CodeBlock.h:
2583         (JSC::CodeBlock::symbolTable):
2584         * runtime/Executable.cpp:
2585         (JSC::FunctionExecutable::symbolTable):
2586         * runtime/Executable.h:
2587         * runtime/SymbolTable.cpp:
2588         (JSC::SymbolTable::clone):
2589         * runtime/SymbolTable.h:
2590
2591 2013-11-26  Oliver Hunt  <oliver@apple.com>
2592
2593         Crash in JSC::ASTBuilder::Expression JSC::Parser<JSC::Lexer<unsigned char> >::parseUnaryExpression<JSC::ASTBuilder>(JSC::ASTBuilder&)
2594         https://bugs.webkit.org/show_bug.cgi?id=124886
2595
2596         Reviewed by Sam Weinig.
2597
2598         Make sure the error macros propagate an existing error before
2599         trying to create a new error message.  We need to do this as
2600         the parser state may not be safe for any specific error message
2601         if we are already unwinding due to an error.
2602
2603         * parser/Parser.cpp:
2604
2605 2013-11-26  Nadav Rotem  <nrotem@apple.com>
2606
2607         Optimize away OR with zero - a common ASM.js pattern.
2608         https://bugs.webkit.org/show_bug.cgi?id=124869
2609
2610         Reviewed by Filip Pizlo.
2611
2612         * dfg/DFGFixupPhase.cpp:
2613         (JSC::DFG::FixupPhase::fixupNode):
2614
2615 2013-11-25  Julien Brianceau  <jbriance@cisco.com>
2616
2617         [arm][mips] Fix crash in dfg-arrayify-elimination layout jsc test.
2618         https://bugs.webkit.org/show_bug.cgi?id=124839
2619
2620         Reviewed by Michael Saboff.
2621
2622         In ARM EABI and MIPS, 64-bit values have to be aligned on stack too.
2623
2624         * jit/CCallHelpers.h:
2625         (JSC::CCallHelpers::setupArgumentsWithExecState):
2626         * jit/JITInlines.h:
2627         (JSC::JIT::callOperation): Add missing EABI_32BIT_DUMMY_ARG.
2628
2629 2013-11-23  Filip Pizlo  <fpizlo@apple.com>
2630
2631         Fix more fallout from failed attempts at div/mod DFG strength reductions
2632         https://bugs.webkit.org/show_bug.cgi?id=124813
2633
2634         Reviewed by Geoffrey Garen.
2635
2636         * dfg/DFGSpeculativeJIT.cpp:
2637         (JSC::DFG::SpeculativeJIT::compileArithMod):
2638
2639 2013-11-22  Mark Hahnenberg  <mhahnenberg@apple.com>
2640
2641         JSC Obj-C API should have real documentation
2642         https://bugs.webkit.org/show_bug.cgi?id=124805
2643
2644         Reviewed by Geoffrey Garen.
2645
2646         Massaging the header comments into proper headerdocs.
2647
2648         * API/JSContext.h:
2649         * API/JSExport.h:
2650         * API/JSManagedValue.h:
2651         * API/JSValue.h:
2652         * API/JSVirtualMachine.h:
2653
2654 2013-11-22  Filip Pizlo  <fpizlo@apple.com>
2655
2656         CodeBlock::m_numCalleeRegisters shouldn't also mean frame size, frame size needed for exit, or any other unrelated things
2657         https://bugs.webkit.org/show_bug.cgi?id=124793
2658
2659         Reviewed by Mark Hahnenberg.
2660         
2661         Now m_numCalleeRegisters always refers to the number of locals that the attached
2662         bytecode uses. It never means anything else.
2663         
2664         For frame size, we now have it lazily computed from m_numCalleeRegisters for the
2665         baseline engines and we have it stored in DFG::CommonData for the optimizing JITs.
2666         
2667         For frame-size-needed-at-exit, we store that in DFG::CommonData, too.
2668         
2669         The code no longer implies that there is any arithmetic relationship between
2670         m_numCalleeRegisters and frameSize. Previously it implied that the latter is greater
2671         than the former.
2672         
2673         The code no longer implies that there is any arithmetic relationship between the
2674         frame Size and the frame-size-needed-at-exit. Previously it implied that the latter
2675         is greater that the former.
2676
2677         * bytecode/CodeBlock.cpp:
2678         (JSC::CodeBlock::frameRegisterCount):
2679         * bytecode/CodeBlock.h:
2680         * dfg/DFGCommonData.h:
2681         (JSC::DFG::CommonData::CommonData):
2682         (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit):
2683         * dfg/DFGGraph.cpp:
2684         (JSC::DFG::Graph::frameRegisterCount):
2685         (JSC::DFG::Graph::requiredRegisterCountForExit):
2686         (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit):
2687         * dfg/DFGGraph.h:
2688         * dfg/DFGJITCompiler.cpp:
2689         (JSC::DFG::JITCompiler::link):
2690         (JSC::DFG::JITCompiler::compileFunction):
2691         * dfg/DFGOSREntry.cpp:
2692         (JSC::DFG::prepareOSREntry):
2693         * dfg/DFGSpeculativeJIT.cpp:
2694         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
2695         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2696         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2697         * ftl/FTLLink.cpp:
2698         (JSC::FTL::link):
2699         * ftl/FTLLowerDFGToLLVM.cpp:
2700         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
2701         * ftl/FTLOSREntry.cpp:
2702         (JSC::FTL::prepareOSREntry):
2703         * interpreter/CallFrame.cpp:
2704         (JSC::CallFrame::frameExtentInternal):
2705         * interpreter/JSStackInlines.h:
2706         (JSC::JSStack::pushFrame):
2707         * jit/JIT.h:
2708         (JSC::JIT::frameRegisterCountFor):
2709         * jit/JITOperations.cpp:
2710         * llint/LLIntEntrypoint.cpp:
2711         (JSC::LLInt::frameRegisterCountFor):
2712         * llint/LLIntEntrypoint.h:
2713
2714 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
2715
2716         Combine SymbolTable and SharedSymbolTable
2717         https://bugs.webkit.org/show_bug.cgi?id=124761
2718
2719         Reviewed by Geoffrey Garen.
2720         
2721         SymbolTable was never used directly; we now always used SharedSymbolTable. So, this
2722         gets rid of SymbolTable and renames SharedSymbolTable to SymbolTable.
2723
2724         * bytecode/CodeBlock.h:
2725         (JSC::CodeBlock::symbolTable):
2726         * bytecode/UnlinkedCodeBlock.h:
2727         (JSC::UnlinkedFunctionExecutable::symbolTable):
2728         (JSC::UnlinkedCodeBlock::symbolTable):
2729         (JSC::UnlinkedCodeBlock::finishCreation):
2730         * bytecompiler/BytecodeGenerator.h:
2731         (JSC::BytecodeGenerator::symbolTable):
2732         * dfg/DFGSpeculativeJIT32_64.cpp:
2733         (JSC::DFG::SpeculativeJIT::compile):
2734         * dfg/DFGSpeculativeJIT64.cpp:
2735         (JSC::DFG::SpeculativeJIT::compile):
2736         * dfg/DFGStackLayoutPhase.cpp:
2737         (JSC::DFG::StackLayoutPhase::run):
2738         * jit/AssemblyHelpers.h:
2739         (JSC::AssemblyHelpers::symbolTableFor):
2740         * runtime/Arguments.h:
2741         (JSC::Arguments::finishCreation):
2742         * runtime/Executable.h:
2743         (JSC::FunctionExecutable::symbolTable):
2744         * runtime/JSActivation.h:
2745         (JSC::JSActivation::create):
2746         (JSC::JSActivation::JSActivation):
2747         (JSC::JSActivation::registersOffset):
2748         (JSC::JSActivation::allocationSize):
2749         * runtime/JSSymbolTableObject.h:
2750         (JSC::JSSymbolTableObject::symbolTable):
2751         (JSC::JSSymbolTableObject::JSSymbolTableObject):
2752         (JSC::JSSymbolTableObject::finishCreation):
2753         * runtime/JSVariableObject.h:
2754         (JSC::JSVariableObject::JSVariableObject):
2755         * runtime/SymbolTable.cpp:
2756         (JSC::SymbolTable::destroy):
2757         (JSC::SymbolTable::SymbolTable):
2758         * runtime/SymbolTable.h:
2759         (JSC::SymbolTable::create):
2760         (JSC::SymbolTable::createStructure):
2761         * runtime/VM.cpp:
2762         (JSC::VM::VM):
2763         * runtime/VM.h:
2764
2765 2013-11-22  Mark Lam  <mark.lam@apple.com>
2766
2767         Remove residual references to "dynamicGlobalObject".
2768         https://bugs.webkit.org/show_bug.cgi?id=124787.
2769
2770         Reviewed by Filip Pizlo.
2771
2772         * JavaScriptCore.order:
2773         * interpreter/CallFrame.h:
2774
2775 2013-11-22  Mark Lam  <mark.lam@apple.com>
2776
2777         Ensure that arity fixups honor stack alignment requirements.
2778         https://bugs.webkit.org/show_bug.cgi?id=124756.
2779
2780         Reviewed by Geoffrey Garen.
2781
2782         The LLINT and all the JITs rely on CommonSlowPaths::arityCheckFor() to
2783         compute the arg count adjustment for the arity fixup. We take advantage
2784         of this choke point and introduce the stack alignment padding there in
2785         the guise of additional args.
2786
2787         The only cost of this approach is that the padding will also be
2788         initialized to undefined values as if they were args. Since arity fixups
2789         are considered a slow path that is rarely taken, this cost is not a
2790         concern.
2791
2792         * runtime/CommonSlowPaths.h:
2793         (JSC::CommonSlowPaths::arityCheckFor):
2794         * runtime/VM.h:
2795         (JSC::VM::isSafeToRecurse):
2796
2797 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
2798
2799         BytecodeGenerator should align the stack according to native conventions
2800         https://bugs.webkit.org/show_bug.cgi?id=124735
2801
2802         Reviewed by Mark Lam.
2803         
2804         Rolling this back in because it actually fixed fast/dom/gc-attribute-node.html, but
2805         our infrastructure misleads peole into thinking that fixing a test constitutes
2806         breaking it.
2807
2808         * bytecompiler/BytecodeGenerator.h:
2809         (JSC::CallArguments::registerOffset):
2810         (JSC::CallArguments::argumentCountIncludingThis):
2811         * bytecompiler/NodesCodegen.cpp:
2812         (JSC::CallArguments::CallArguments):
2813
2814 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
2815
2816         Get rid of CodeBlock::dumpStatistics()
2817         https://bugs.webkit.org/show_bug.cgi?id=124762
2818
2819         Reviewed by Mark Hahnenberg.
2820
2821         * bytecode/CodeBlock.cpp:
2822         (JSC::CodeBlock::CodeBlock):
2823         (JSC::CodeBlock::~CodeBlock):
2824         * bytecode/CodeBlock.h:
2825
2826 2013-11-22  Commit Queue  <commit-queue@webkit.org>
2827
2828         Unreviewed, rolling out r159652.
2829         http://trac.webkit.org/changeset/159652
2830         https://bugs.webkit.org/show_bug.cgi?id=124778
2831
2832         broke fast/dom/gc-attribute-node.html (Requested by ap on
2833         #webkit).
2834
2835         * bytecompiler/BytecodeGenerator.cpp:
2836         (JSC::BytecodeGenerator::emitCall):
2837         (JSC::BytecodeGenerator::emitConstruct):
2838         * bytecompiler/BytecodeGenerator.h:
2839         (JSC::CallArguments::registerOffset):
2840         (JSC::CallArguments::argumentCountIncludingThis):
2841         * bytecompiler/NodesCodegen.cpp:
2842         (JSC::CallArguments::CallArguments):
2843         (JSC::CallArguments::newArgument):
2844
2845 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
2846
2847         Fix a typo (requriements->requirements).
2848
2849         * runtime/StackAlignment.h:
2850
2851 2013-11-21  Mark Lam  <mark.lam@apple.com>
2852
2853         CodeBlock::m_numCalleeRegisters need to honor native stack alignment.
2854         https://bugs.webkit.org/show_bug.cgi?id=124754.
2855
2856         Reviewed by Filip Pizlo.
2857
2858         * bytecompiler/BytecodeGenerator.cpp:
2859         (JSC::BytecodeGenerator::newRegister):
2860         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2861         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2862
2863 2013-11-21  Mark Rowe  <mrowe@apple.com>
2864
2865         <https://webkit.org/b/124702> Stop overriding VALID_ARCHS.
2866
2867         All modern versions of Xcode set it appropriately for our needs.
2868
2869         Reviewed by Alexey Proskuryakov.
2870
2871         * Configurations/Base.xcconfig:
2872
2873 2013-11-21  Mark Rowe  <mrowe@apple.com>
2874
2875         <https://webkit.org/b/124701> Fix an error in a few Xcode configuration setting files.
2876
2877         Reviewed by Alexey Proskuryakov.
2878
2879         * Configurations/Base.xcconfig:
2880
2881 2013-11-21  Michael Saboff  <msaboff@apple.com>
2882
2883         ARM64: Implement push/pop equivalents in LLInt
2884         https://bugs.webkit.org/show_bug.cgi?id=124721
2885
2886         Reviewed by Filip Pizlo.
2887
2888         Added pushLRAndFP and popLRAndFP that push and pop the link register and frame pointer register.
2889         These ops emit code just like what the compiler emits in the prologue and epilogue.  Also changed
2890         pushCalleeSaves and popCalleeSaves to use the same store pair and load pair instructions to do
2891         the actually pushing and popping.  Finally changed the implementation of push and pop to raise
2892         an exception since we don't have (or need) a single register push or pop.
2893
2894         * llint/LowLevelInterpreter64.asm:
2895         * offlineasm/arm64.rb:
2896         * offlineasm/instructions.rb:
2897
2898 2013-11-21  Michael Saboff  <msaboff@apple.com>
2899
2900         JSC: Removed unused opcodes from offline assembler
2901         https://bugs.webkit.org/show_bug.cgi?id=124749
2902
2903         Reviewed by Mark Hahnenberg.
2904
2905         Removed the unused, X86 only peekq and pokeq.
2906
2907         * offlineasm/instructions.rb:
2908         * offlineasm/x86.rb:
2909
2910 2013-11-21  Michael Saboff  <msaboff@apple.com>
2911
2912         REGRESSION(159395) Fix branch8(…, AbsoluteAddress, …) in ARM64 MacroAssembler
2913         https://bugs.webkit.org/show_bug.cgi?id=124688
2914
2915         Reviewed by Geoffrey Garen.
2916
2917         Changed handling of the address for the load8() in the branch8(AbsoluteAddress) to be like
2918         the rest of the branchXX(AbsoluteAddress) fucntions.
2919
2920         * assembler/MacroAssemblerARM64.h:
2921         (JSC::MacroAssemblerARM64::branch8):
2922
2923 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
2924
2925         BytecodeGenerator should align the stack according to native conventions
2926         https://bugs.webkit.org/show_bug.cgi?id=124735
2927
2928         Reviewed by Mark Lam.
2929
2930         * bytecompiler/BytecodeGenerator.h:
2931         (JSC::CallArguments::registerOffset):
2932         (JSC::CallArguments::argumentCountIncludingThis):
2933         * bytecompiler/NodesCodegen.cpp:
2934         (JSC::CallArguments::CallArguments):
2935
2936 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
2937
2938         Unreviewed, preemptive build fix.
2939
2940         * runtime/StackAlignment.h:
2941         (JSC::stackAlignmentBytes):
2942         (JSC::stackAlignmentRegisters):
2943
2944 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
2945
2946         JSC should know what the stack alignment conventions are
2947         https://bugs.webkit.org/show_bug.cgi?id=124736
2948
2949         Reviewed by Mark Lam.
2950
2951         * GNUmakefile.list.am:
2952         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2953         * JavaScriptCore.xcodeproj/project.pbxproj:
2954         * runtime/StackAlignment.h: Added.
2955         (JSC::stackAlignmentBytes):
2956         (JSC::stackAlignmentRegisters):
2957
2958 2013-11-21  Balazs Kilvady  <kilvadyb@homejinni.com>
2959
2960         [MIPS] Build fails since r159545.
2961         https://bugs.webkit.org/show_bug.cgi?id=124716
2962
2963         Reviewed by Michael Saboff.
2964
2965         Add missing implementations in MacroAssembler and LLInt for MIPS.
2966
2967         * assembler/MIPSAssembler.h:
2968         (JSC::MIPSAssembler::sync):
2969         * assembler/MacroAssemblerMIPS.h:
2970         (JSC::MacroAssemblerMIPS::store8):
2971         (JSC::MacroAssemblerMIPS::memoryFence):
2972         * offlineasm/mips.rb:
2973
2974 2013-11-21  Julien Brianceau  <jbriance@cisco.com>
2975
2976         Fix sh4 build after r159545.
2977         https://bugs.webkit.org/show_bug.cgi?id=124713
2978
2979         Reviewed by Michael Saboff.
2980
2981         Add missing implementations in macro assembler and LLINT for sh4.
2982
2983         * assembler/MacroAssemblerSH4.h:
2984         (JSC::MacroAssemblerSH4::load8):
2985         (JSC::MacroAssemblerSH4::store8):
2986         (JSC::MacroAssemblerSH4::memoryFence):
2987         * assembler/SH4Assembler.h:
2988         (JSC::SH4Assembler::synco):
2989         * offlineasm/sh4.rb: Handle "memfence" opcode.
2990
2991 2013-11-20  Mark Lam  <mark.lam@apple.com>
2992
2993         Introducing VMEntryScope to update the VM stack limit.
2994         https://bugs.webkit.org/show_bug.cgi?id=124634.
2995
2996         Reviewed by Geoffrey Garen.
2997
2998         1. Introduced USE(SEPARATE_C_AND_JS_STACK) (defined in Platform.h).
2999            Currently, it is hardcoded to use separate C and JS stacks. Once we
3000            switch to using the C stack for JS frames, we'll need to fix this to
3001            only be enabled when ENABLE(LLINT_C_LOOP).
3002
3003         2. Stack limits are now tracked in the VM.
3004
3005            Logically, there are 2 stack limits:
3006            a. m_stackLimit for the native C stack, and
3007            b. m_jsStackLimit for the JS stack.
3008
3009            If USE(SEPARATE_C_AND_JS_STACK), then the 2 limits are the same
3010            value, and are implemented as 2 fields in a union.
3011
3012         3. The VM native stackLimit is set as follows:
3013            a. Initially, the VM sets it to the limit of the stack of the thread that
3014               instantiated the VM. This allows the parser and bytecode generator to
3015               run before we enter the VM to execute JS code.
3016
3017            b. Upon entry into the VM to execute JS code (via one of the
3018               Interpreter::execute...() functions), we instantiate a VMEntryScope
3019               that sets the VM's stackLimit to the limit of the current thread's
3020               stack. The VMEntryScope will automatically restore the previous
3021               entryScope and stack limit upon destruction.
3022
3023            If USE(SEPARATE_C_AND_JS_STACK), the JSStack's methods will set the VM's
3024            jsStackLimit whenever it grows or shrinks.
3025
3026         4. The VM now provides a isSafeToRecurse() function that compares the
3027            current stack pointer against its native stackLimit. This subsumes and
3028            obsoletes the VMStackBounds class.
3029
3030         5. The VMEntryScope class also subsumes DynamicGlobalObjectScope for
3031            tracking the JSGlobalObject that we last entered the VM with.
3032
3033         6. Renamed dynamicGlobalObject() to vmEntryGlobalObject() since that is
3034            the value that the function retrieves.
3035
3036         7. Changed JIT and LLINT code to do stack checks against the jsStackLimit
3037            in the VM class instead of the JSStack.
3038
3039         * API/JSBase.cpp:
3040         (JSEvaluateScript):
3041         (JSCheckScriptSyntax):
3042         * API/JSContextRef.cpp:
3043         (JSGlobalContextRetain):
3044         (JSGlobalContextRelease):
3045         * CMakeLists.txt:
3046         * GNUmakefile.list.am:
3047         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3048         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3049         * JavaScriptCore.xcodeproj/project.pbxproj:
3050         * bytecompiler/BytecodeGenerator.cpp:
3051         (JSC::BytecodeGenerator::BytecodeGenerator):
3052         * bytecompiler/BytecodeGenerator.h:
3053         (JSC::BytecodeGenerator::emitNode):
3054         (JSC::BytecodeGenerator::emitNodeInConditionContext):
3055         * debugger/Debugger.cpp:
3056         (JSC::Debugger::detach):
3057         (JSC::Debugger::recompileAllJSFunctions):
3058         (JSC::Debugger::pauseIfNeeded):
3059         * debugger/DebuggerCallFrame.cpp:
3060         (JSC::DebuggerCallFrame::vmEntryGlobalObject):
3061         * debugger/DebuggerCallFrame.h:
3062         * dfg/DFGJITCompiler.cpp:
3063         (JSC::DFG::JITCompiler::compileFunction):
3064         * dfg/DFGOSREntry.cpp:
3065         * ftl/FTLLink.cpp:
3066         (JSC::FTL::link):
3067         * ftl/FTLOSREntry.cpp:
3068         * heap/Heap.cpp:
3069         (JSC::Heap::lastChanceToFinalize):
3070         (JSC::Heap::deleteAllCompiledCode):
3071         * interpreter/CachedCall.h:
3072         (JSC::CachedCall::CachedCall):
3073         * interpreter/CallFrame.cpp:
3074         (JSC::CallFrame::vmEntryGlobalObject):
3075         * interpreter/CallFrame.h:
3076         * interpreter/Interpreter.cpp:
3077         (JSC::unwindCallFrame):
3078         (JSC::Interpreter::unwind):
3079         (JSC::Interpreter::execute):
3080         (JSC::Interpreter::executeCall):
3081         (JSC::Interpreter::executeConstruct):
3082         (JSC::Interpreter::prepareForRepeatCall):
3083         (JSC::Interpreter::debug):
3084         * interpreter/JSStack.cpp:
3085         (JSC::JSStack::JSStack):
3086         (JSC::JSStack::growSlowCase):
3087         * interpreter/JSStack.h:
3088         * interpreter/JSStackInlines.h:
3089         (JSC::JSStack::shrink):
3090         (JSC::JSStack::grow):
3091         - Moved these inlined functions here from JSStack.h. It reduces some
3092           #include dependencies of JSSTack.h which had previously resulted
3093           in some EWS bots' unhappiness with this patch.
3094         (JSC::JSStack::updateStackLimit):
3095         * jit/JIT.cpp:
3096         (JSC::JIT::privateCompile):
3097         * jit/JITCall.cpp:
3098         (JSC::JIT::compileLoadVarargs):
3099         * jit/JITCall32_64.cpp:
3100         (JSC::JIT::compileLoadVarargs):
3101         * jit/JITOperations.cpp:
3102         * llint/LLIntSlowPaths.cpp:
3103         * llint/LowLevelInterpreter.asm:
3104         * parser/Parser.cpp:
3105         (JSC::::Parser):
3106         * parser/Parser.h:
3107         (JSC::Parser::canRecurse):
3108         * runtime/CommonSlowPaths.h:
3109         * runtime/Completion.cpp:
3110         (JSC::evaluate):
3111         * runtime/FunctionConstructor.cpp:
3112         (JSC::constructFunctionSkippingEvalEnabledCheck):
3113         * runtime/JSGlobalObject.cpp:
3114         * runtime/JSGlobalObject.h:
3115         * runtime/StringRecursionChecker.h:
3116         (JSC::StringRecursionChecker::performCheck):
3117         * runtime/VM.cpp:
3118         (JSC::VM::VM):
3119         (JSC::VM::releaseExecutableMemory):
3120         (JSC::VM::throwException):
3121         * runtime/VM.h:
3122         (JSC::VM::addressOfJSStackLimit):
3123         (JSC::VM::jsStackLimit):
3124         (JSC::VM::setJSStackLimit):
3125         (JSC::VM::stackLimit):
3126         (JSC::VM::setStackLimit):
3127         (JSC::VM::isSafeToRecurse):
3128         * runtime/VMEntryScope.cpp: Added.
3129         (JSC::VMEntryScope::VMEntryScope):
3130         (JSC::VMEntryScope::~VMEntryScope):
3131         (JSC::VMEntryScope::requiredCapacity):
3132         * runtime/VMEntryScope.h: Added.
3133         (JSC::VMEntryScope::globalObject):
3134         * runtime/VMStackBounds.h: Removed.
3135
3136 2013-11-20  Michael Saboff  <msaboff@apple.com>
3137
3138         [Win] JavaScript JIT crash (with DFG enabled).
3139         https://bugs.webkit.org/show_bug.cgi?id=124675
3140
3141         Reviewed by Geoffrey Garen.
3142
3143         Similar to the change in r159427, changed linkClosureCall to use regT0/regT1 (payload/tag) for the callee.
3144         linkForThunkGenerator already expected the callee in regT0/regT1, but changed the comment to reflect that.
3145
3146         * jit/Repatch.cpp:
3147         (JSC::linkClosureCall):
3148         * jit/ThunkGenerators.cpp:
3149         (JSC::linkForThunkGenerator):
3150
3151 2013-11-20  Michael Saboff  <msaboff@apple.com>
3152
3153         ARMv7: Crash due to use after free of AssemblerBuffer
3154         https://bugs.webkit.org/show_bug.cgi?id=124611
3155
3156         Reviewed by Geoffrey Garen.
3157
3158         Changed JITFinalizer constructor to take a MacroAssemblerCodePtr instead of a Label.
3159         In finalizeFunction(), we use that value instead of calculating it from the label.
3160
3161         * assembler/MacroAssembler.cpp:
3162         * dfg/DFGJITFinalizer.cpp:
3163         (JSC::DFG::JITFinalizer::JITFinalizer):
3164         (JSC::DFG::JITFinalizer::finalizeFunction):
3165         * dfg/DFGJITFinalizer.h:
3166
3167 2013-11-20  Julien Brianceau  <jbriance@cisco.com>
3168
3169         Fix CPU(ARM_TRADITIONAL) build after r159545.
3170         https://bugs.webkit.org/show_bug.cgi?id=124649
3171
3172         Reviewed by Michael Saboff.
3173
3174         Add missing memoryFence, load8 and store8 implementations in macro assembler.
3175
3176         * assembler/ARMAssembler.h:
3177         (JSC::ARMAssembler::dmbSY):
3178         * assembler/MacroAssemblerARM.h:
3179         (JSC::MacroAssemblerARM::load8):
3180         (JSC::MacroAssemblerARM::store8):
3181         (JSC::MacroAssemblerARM::memoryFence):
3182
3183 2013-11-20  Julien Brianceau  <jbriance@cisco.com>
3184
3185         [armv7][arm64] Speculative build fix after r159545.
3186         https://bugs.webkit.org/show_bug.cgi?id=124646
3187
3188         Reviewed by Filip Pizlo.
3189
3190         * assembler/ARMv7Assembler.h:
3191         * assembler/MacroAssemblerARM64.h:
3192         (JSC::MacroAssemblerARM64::memoryFence):
3193         * assembler/MacroAssemblerARMv7.h:
3194         (JSC::MacroAssemblerARMv7::memoryFence):
3195
3196 2013-11-19  Ryosuke Niwa  <rniwa@webkit.org>
3197
3198         Enable HTMLTemplateElement on Mac port
3199         https://bugs.webkit.org/show_bug.cgi?id=124637
3200
3201         Reviewed by Tim Horton.
3202
3203         * Configurations/FeatureDefines.xcconfig:
3204
3205 2013-11-19  Filip Pizlo  <fpizlo@apple.com>
3206
3207         Unreviewed, remove completely bogus assertion.
3208
3209         * runtime/JSGlobalObject.cpp:
3210         (JSC::JSGlobalObject::addFunction):
3211
3212 2013-11-19  Filip Pizlo  <fpizlo@apple.com>
3213
3214         Unreviewed, debug build fix.
3215
3216         * runtime/JSGlobalObject.cpp:
3217         (JSC::JSGlobalObject::addFunction):
3218
3219 2013-11-19  Filip Pizlo  <fpizlo@apple.com>
3220
3221         Infer constant global variables
3222         https://bugs.webkit.org/show_bug.cgi?id=124464
3223
3224         Reviewed by Sam Weinig.
3225         
3226         All global variables that are candidates for watchpoint-based constant inference (i.e.
3227         not 'const' variables) will now have WatchpointSet's associated with them and those
3228         are used to drive the inference by tracking three states of each variable:
3229         
3230         Uninitialized: the variable's value is Undefined and the WatchpointSet state is
3231             ClearWatchpoint.
3232         
3233         Initialized: the variable's value was set to something (could even be explicitly set
3234             to Undefined) and the WatchpointSet state is IsWatching.
3235         
3236         Invalidated: the variable's value was set to something else (could even be the same
3237             thing as before but the point is that a put operation did execute again) and the
3238             WatchpointSet is IsInvalidated.
3239         
3240         If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is
3241         IsWatching, then the current value of the variable can be folded in place of the get,
3242         and a watchpoint on the variable can be registered.
3243         
3244         We handle race conditions between the mutator and compiler by mandating that:
3245         
3246         - The mutator changes the WatchpointSet state after executing the put.
3247         
3248         - There is no opportunity to install code or call functions between when the mutator
3249           executes a put and changes the WatchpointSet state.
3250         
3251         - The compiler checks the WatchpointSet state prior to reading the value.
3252         
3253         The concrete algorithm used by the mutator is:
3254         
3255             1. Store the new value into the variable.
3256             --- Execute a store-store fence.
3257             2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes
3258                IsInvalidated); the IsWatching->IsInvalidated transition may end up firing
3259                watchpoints.
3260         
3261         The concrete algorithm that the compiler uses is:
3262         
3263             1. Load the state. If it's *not* IsWatching, then give up on constant inference.
3264             --- Execute a load-load fence.
3265             2. Load the value of the variable and use that for folding, while also registering
3266                a DesiredWatchpoint. The various parts of this step can be done in any order.
3267         
3268         The desired watchpoint registration will fail if the watchpoint set is already
3269         invalidated. Now consider the following interesting interleavings:
3270         
3271         Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store
3272             operation, and the variable is folded. The fencing ensures that C2 sees the value
3273             stored in M1 - i.e. we fold on the value that will actually be watchpointed. If
3274             before the compilation is installed the mutator executes another store then we
3275             will be sure that it will be a complete sequence of M1+M2 since compilations get
3276             installed at safepoints and never "in the middle" of a put_to_scope. Hence that
3277             compilation installation will be invalidated. If the M1+M2 sequence happens after
3278             the code is installed, then the code will be invalidated by triggering a jettison.
3279         
3280         Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is
3281             a sensible outcome since if the compiler read the variable's value, it would have
3282             seen Undefined.
3283         
3284         Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold.
3285         Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold.
3286         Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold.
3287         Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold.
3288         
3289         IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold.
3290         
3291         IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired
3292             watchpoint, and that watchpoint will get invalidated before the code is installed.
3293         
3294         IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated.
3295         IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated.
3296         IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated.
3297         IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated.
3298         
3299         Note that this kind of reasoning shows why having the mutator first bump the state and
3300         then store the new value would be wrong. If we had done that (M1 = bump state, M2 =
3301         execute put) then we could have the following deadly interleavings:
3302         
3303         Uninitialized->M1->C1->C2->M2:
3304         Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the
3305             compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the
3306             watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a
3307             value other than Undefined, and you're toast.
3308         
3309         You could fix this sort of thing by making the Desired Watchpoints machinery more
3310         sophisticated, for example having it track the value that was folded; if the global
3311         variable's value was later found to be different then we could invalidate the
3312         compilation. You could also fix it by having the compiler also check that the value of
3313         the variable is not Undefined before folding. While those all sound great, I decided
3314         to instead just use the right interleaving since that results in less code and feels
3315         more intuitive.
3316         
3317         This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic.
3318         It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is
3319         because 3d-cube takes global variable assignment slow paths very often. Note that this
3320         3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is
3321         also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue
3322         (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due
3323         to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the
3324         slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS
3325         programming often leads to global-var-based idioms and those variables tend to be
3326         assigned once, leading to excellent constant folding opportunities in an optimizing
3327         JIT. This is very evident in the speed-ups on JSRegress.
3328
3329         * assembler/ARM64Assembler.h:
3330         (JSC::ARM64Assembler::dmbSY):
3331         * assembler/ARMv7Assembler.h:
3332         (JSC::ARMv7Assembler::dmbSY):
3333         * assembler/MacroAssemblerARM64.h:
3334         (JSC::MacroAssemblerARM64::memfence):
3335         * assembler/MacroAssemblerARMv7.h:
3336         (JSC::MacroAssemblerARMv7::load8):
3337         (JSC::MacroAssemblerARMv7::memfence):
3338         * assembler/MacroAssemblerX86.h:
3339         (JSC::MacroAssemblerX86::load8):
3340         (JSC::MacroAssemblerX86::store8):
3341         * assembler/MacroAssemblerX86Common.h:
3342         (JSC::MacroAssemblerX86Common::getUnusedRegister):
3343         (JSC::MacroAssemblerX86Common::store8):
3344         (JSC::MacroAssemblerX86Common::memoryFence):
3345         * assembler/MacroAssemblerX86_64.h:
3346         (JSC::MacroAssemblerX86_64::load8):
3347         (JSC::MacroAssemblerX86_64::store8):
3348         * assembler/X86Assembler.h:
3349         (JSC::X86Assembler::movb_rm):
3350         (JSC::X86Assembler::movzbl_mr):
3351         (JSC::X86Assembler::mfence):
3352         (JSC::X86Assembler::X86InstructionFormatter::threeByteOp):
3353         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8):
3354         * bytecode/CodeBlock.cpp:
3355         (JSC::CodeBlock::CodeBlock):
3356         * bytecode/Watchpoint.cpp:
3357         (JSC::WatchpointSet::WatchpointSet):
3358         (JSC::WatchpointSet::add):
3359         (JSC::WatchpointSet::notifyWriteSlow):
3360         * bytecode/Watchpoint.h:
3361         (JSC::WatchpointSet::state):
3362         (JSC::WatchpointSet::isStillValid):
3363         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
3364         * dfg/DFGAbstractInterpreterInlines.h:
3365         (JSC::DFG::::executeEffects):
3366         * dfg/DFGByteCodeParser.cpp:
3367         (JSC::DFG::ByteCodeParser::getJSConstantForValue):
3368         (JSC::DFG::ByteCodeParser::getJSConstant):
3369         (JSC::DFG::ByteCodeParser::parseBlock):
3370         * dfg/DFGClobberize.h:
3371         (JSC::DFG::clobberize):
3372         * dfg/DFGFixupPhase.cpp:
3373         (JSC::DFG::FixupPhase::fixupNode):
3374         * dfg/DFGNode.h:
3375         (JSC::DFG::Node::isStronglyProvedConstantIn):
3376         (JSC::DFG::Node::hasIdentifierNumberForCheck):
3377         (JSC::DFG::Node::hasRegisterPointer):
3378         * dfg/DFGNodeFlags.h: