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