4aa0c4be67f74c787a53a74fbb5f65b0d980449a
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2013-11-27  Andreas Kling  <akling@apple.com>
2
3         JSActivation constructor should use NotNull placement new.
4         <https://webkit.org/b/124909>
5
6         Knock a null check outta the storage initialization loop.
7
8         Reviewed by Antti Koivisto.
9
10 2013-11-26  Filip Pizlo  <fpizlo@apple.com>
11
12         Restructure global variable constant inference so that it could work for any kind of symbol table variable
13         https://bugs.webkit.org/show_bug.cgi?id=124760
14
15         Reviewed by Oliver Hunt.
16         
17         This changes the way global variable constant inference works so that it can be reused
18         for closure variable constant inference. Some of the premises that originally motivated
19         this patch are somewhat wrong, but it led to some simplifications anyway and I suspect
20         that we'll be able to fix those premises in the future. The main point of this patch is
21         to make it easy to reuse global variable constant inference for closure variable
22         constant inference, and this will be possible provided we can also either (a) infer
23         one-shot closures (easy) or (b) infer closure variables that are always assigned prior
24         to first use.
25         
26         One of the things that this patch is meant to enable is constant inference for closure
27         variables that may be part of a multi-shot closure. Closure variables may be
28         instantiated multiple times, like:
29         
30             function foo() {
31                 var WIDTH = 45;
32                 function bar() {
33                     ... use WIDTH ...
34                 }
35                 ...
36             }
37         
38         Even if foo() is called many times and WIDTH is assigned to multiple times, that
39         doesn't change the fact that it's a constant. The goal of closure variable constant
40         inference is to catch any case where a closure variable has been assigned at least once
41         and its value has never changed. This patch doesn't implement that, but it does change
42         global variable constant inference to have most of the powers needed to do that. Note
43         that most likely we will use this functionality only to implement constant inference
44         for one-shot closures, but the resulting machinery is still simpler than what we had
45         before.
46         
47         This involves three changes:
48         
49             - The watchpoint object now contains the inferred value. This involves creating a
50               new kind of watchpoint set, the VariableWatchpointSet. We will reuse this object
51               for closure variables.
52         
53             - Writing to a variable that is watchpointed still involves these three states that
54               we proceed through monotonically (Uninitialized->Initialized->Invalidated) but
55               now, the Initialized->Invalidated state transition only happens if we change the
56               variable's value, rather than store to the variable. Repeatedly storing the same
57               value won't change the variable's state.
58         
59             - On 64-bit systems (the only systems on which we do concurrent JIT), you no longer
60               need fancy fencing to get a consistent view of the watchpoint in the JIT. The
61               state of the VariableWatchpointSet for the purposes of constant folding is
62               entirely encapsulated in the VariableWatchpointSet::m_inferredValue. If that is
63               JSValue() then you cannot fold (either because the set is uninitialized or
64               because it's invalidated - doesn't matter which); on the other hand if the value
65               is anything other than JSValue() then you can fold, and that's the value you fold
66               to. Simple!
67         
68         This also changes the way that DFG IR deals with variable watchpoints. It's now
69         oblivious to global variables. You install a watchpoint using VariableWatchpoint and
70         you notify write using NotifyWrite. Easy!
71         
72         Note that this will requires some more tweaks because of the fact that op_enter will
73         store Undefined into every captured variable. Hence it won't even work for one-shot
74         closures. One-shot closures are easily fixed by introducing another state (so we'll
75         have Uninitialized->Undefined->Initialized->Invalidated). Multi-shot closures will
76         require static analysis. One-shot closures are clearly a higher priority.
77
78         * GNUmakefile.list.am:
79         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
80         * JavaScriptCore.xcodeproj/project.pbxproj:
81         * bytecode/Instruction.h:
82         * bytecode/VariableWatchpointSet.h: Added.
83         (JSC::VariableWatchpointSet::VariableWatchpointSet):
84         (JSC::VariableWatchpointSet::~VariableWatchpointSet):
85         (JSC::VariableWatchpointSet::inferredValue):
86         (JSC::VariableWatchpointSet::notifyWrite):
87         (JSC::VariableWatchpointSet::invalidate):
88         (JSC::VariableWatchpointSet::finalizeUnconditionally):
89         (JSC::VariableWatchpointSet::addressOfInferredValue):
90         * bytecode/Watchpoint.h:
91         * dfg/DFGAbstractInterpreterInlines.h:
92         (JSC::DFG::::executeEffects):
93         * dfg/DFGByteCodeParser.cpp:
94         (JSC::DFG::ByteCodeParser::parseBlock):
95         * dfg/DFGCSEPhase.cpp:
96         (JSC::DFG::CSEPhase::performNodeCSE):
97         * dfg/DFGClobberize.h:
98         (JSC::DFG::clobberize):
99         * dfg/DFGFixupPhase.cpp:
100         (JSC::DFG::FixupPhase::fixupNode):
101         * dfg/DFGNode.h:
102         (JSC::DFG::Node::hasRegisterPointer):
103         (JSC::DFG::Node::hasVariableWatchpointSet):
104         (JSC::DFG::Node::variableWatchpointSet):
105         * dfg/DFGNodeType.h:
106         * dfg/DFGOperations.cpp:
107         * dfg/DFGOperations.h:
108         * dfg/DFGPredictionPropagationPhase.cpp:
109         (JSC::DFG::PredictionPropagationPhase::propagate):
110         * dfg/DFGSafeToExecute.h:
111         (JSC::DFG::safeToExecute):
112         * dfg/DFGSpeculativeJIT.cpp:
113         (JSC::DFG::SpeculativeJIT::compileArithMod):
114         * dfg/DFGSpeculativeJIT.h:
115         (JSC::DFG::SpeculativeJIT::callOperation):
116         * dfg/DFGSpeculativeJIT32_64.cpp:
117         (JSC::DFG::SpeculativeJIT::compile):
118         * dfg/DFGSpeculativeJIT64.cpp:
119         (JSC::DFG::SpeculativeJIT::compile):
120         * dfg/DFGWatchpointCollectionPhase.cpp:
121         (JSC::DFG::WatchpointCollectionPhase::handle):
122         * ftl/FTLCapabilities.cpp:
123         (JSC::FTL::canCompile):
124         * ftl/FTLLowerDFGToLLVM.cpp:
125         (JSC::FTL::LowerDFGToLLVM::compileNode):
126         (JSC::FTL::LowerDFGToLLVM::compileNotifyWrite):
127         * jit/JIT.h:
128         * jit/JITOperations.h:
129         * jit/JITPropertyAccess.cpp:
130         (JSC::JIT::emitNotifyWrite):
131         (JSC::JIT::emitPutGlobalVar):
132         * jit/JITPropertyAccess32_64.cpp:
133         (JSC::JIT::emitNotifyWrite):
134         (JSC::JIT::emitPutGlobalVar):
135         * llint/LowLevelInterpreter32_64.asm:
136         * llint/LowLevelInterpreter64.asm:
137         * runtime/JSGlobalObject.cpp:
138         (JSC::JSGlobalObject::addGlobalVar):
139         (JSC::JSGlobalObject::addFunction):
140         * runtime/JSGlobalObject.h:
141         * runtime/JSScope.h:
142         (JSC::ResolveOp::ResolveOp):
143         * runtime/JSSymbolTableObject.h:
144         (JSC::symbolTablePut):
145         (JSC::symbolTablePutWithAttributes):
146         * runtime/SymbolTable.cpp:
147         (JSC::SymbolTableEntry::inferredValue):
148         (JSC::SymbolTableEntry::prepareToWatch):
149         (JSC::SymbolTableEntry::addWatchpoint):
150         (JSC::SymbolTableEntry::notifyWriteSlow):
151         (JSC::SymbolTable::visitChildren):
152         (JSC::SymbolTable::WatchpointCleanup::WatchpointCleanup):
153         (JSC::SymbolTable::WatchpointCleanup::~WatchpointCleanup):
154         (JSC::SymbolTable::WatchpointCleanup::finalizeUnconditionally):
155         * runtime/SymbolTable.h:
156         (JSC::SymbolTableEntry::watchpointSet):
157         (JSC::SymbolTableEntry::notifyWrite):
158
159 2013-11-24  Filip Pizlo  <fpizlo@apple.com>
160
161         Create a new SymbolTable every time code is loaded so that the watchpoints don't get reused
162         https://bugs.webkit.org/show_bug.cgi?id=124824
163
164         Reviewed by Oliver Hunt.
165         
166         This helps with one shot closure inference as well as closure variable constant
167         inference, since without this, if code was reloaded from the cache then we would
168         think that the first run was actually an Nth run. This would cause us to think that
169         the watchpoint(s) should all be invalidated.
170
171         * bytecode/CodeBlock.cpp:
172         (JSC::CodeBlock::CodeBlock):
173         (JSC::CodeBlock::stronglyVisitStrongReferences):
174         * bytecode/CodeBlock.h:
175         (JSC::CodeBlock::symbolTable):
176         * runtime/Executable.cpp:
177         (JSC::FunctionExecutable::symbolTable):
178         * runtime/Executable.h:
179         * runtime/SymbolTable.cpp:
180         (JSC::SymbolTable::clone):
181         * runtime/SymbolTable.h:
182
183 2013-11-26  Oliver Hunt  <oliver@apple.com>
184
185         Crash in JSC::ASTBuilder::Expression JSC::Parser<JSC::Lexer<unsigned char> >::parseUnaryExpression<JSC::ASTBuilder>(JSC::ASTBuilder&)
186         https://bugs.webkit.org/show_bug.cgi?id=124886
187
188         Reviewed by Sam Weinig.
189
190         Make sure the error macros propagate an existing error before
191         trying to create a new error message.  We need to do this as
192         the parser state may not be safe for any specific error message
193         if we are already unwinding due to an error.
194
195         * parser/Parser.cpp:
196
197 2013-11-26  Nadav Rotem  <nrotem@apple.com>
198
199         Optimize away OR with zero - a common ASM.js pattern.
200         https://bugs.webkit.org/show_bug.cgi?id=124869
201
202         Reviewed by Filip Pizlo.
203
204         * dfg/DFGFixupPhase.cpp:
205         (JSC::DFG::FixupPhase::fixupNode):
206
207 2013-11-25  Julien Brianceau  <jbriance@cisco.com>
208
209         [arm][mips] Fix crash in dfg-arrayify-elimination layout jsc test.
210         https://bugs.webkit.org/show_bug.cgi?id=124839
211
212         Reviewed by Michael Saboff.
213
214         In ARM EABI and MIPS, 64-bit values have to be aligned on stack too.
215
216         * jit/CCallHelpers.h:
217         (JSC::CCallHelpers::setupArgumentsWithExecState):
218         * jit/JITInlines.h:
219         (JSC::JIT::callOperation): Add missing EABI_32BIT_DUMMY_ARG.
220
221 2013-11-23  Filip Pizlo  <fpizlo@apple.com>
222
223         Fix more fallout from failed attempts at div/mod DFG strength reductions
224         https://bugs.webkit.org/show_bug.cgi?id=124813
225
226         Reviewed by Geoffrey Garen.
227
228         * dfg/DFGSpeculativeJIT.cpp:
229         (JSC::DFG::SpeculativeJIT::compileArithMod):
230
231 2013-11-22  Mark Hahnenberg  <mhahnenberg@apple.com>
232
233         JSC Obj-C API should have real documentation
234         https://bugs.webkit.org/show_bug.cgi?id=124805
235
236         Reviewed by Geoffrey Garen.
237
238         Massaging the header comments into proper headerdocs.
239
240         * API/JSContext.h:
241         * API/JSExport.h:
242         * API/JSManagedValue.h:
243         * API/JSValue.h:
244         * API/JSVirtualMachine.h:
245
246 2013-11-22  Filip Pizlo  <fpizlo@apple.com>
247
248         CodeBlock::m_numCalleeRegisters shouldn't also mean frame size, frame size needed for exit, or any other unrelated things
249         https://bugs.webkit.org/show_bug.cgi?id=124793
250
251         Reviewed by Mark Hahnenberg.
252         
253         Now m_numCalleeRegisters always refers to the number of locals that the attached
254         bytecode uses. It never means anything else.
255         
256         For frame size, we now have it lazily computed from m_numCalleeRegisters for the
257         baseline engines and we have it stored in DFG::CommonData for the optimizing JITs.
258         
259         For frame-size-needed-at-exit, we store that in DFG::CommonData, too.
260         
261         The code no longer implies that there is any arithmetic relationship between
262         m_numCalleeRegisters and frameSize. Previously it implied that the latter is greater
263         than the former.
264         
265         The code no longer implies that there is any arithmetic relationship between the
266         frame Size and the frame-size-needed-at-exit. Previously it implied that the latter
267         is greater that the former.
268
269         * bytecode/CodeBlock.cpp:
270         (JSC::CodeBlock::frameRegisterCount):
271         * bytecode/CodeBlock.h:
272         * dfg/DFGCommonData.h:
273         (JSC::DFG::CommonData::CommonData):
274         (JSC::DFG::CommonData::requiredRegisterCountForExecutionAndExit):
275         * dfg/DFGGraph.cpp:
276         (JSC::DFG::Graph::frameRegisterCount):
277         (JSC::DFG::Graph::requiredRegisterCountForExit):
278         (JSC::DFG::Graph::requiredRegisterCountForExecutionAndExit):
279         * dfg/DFGGraph.h:
280         * dfg/DFGJITCompiler.cpp:
281         (JSC::DFG::JITCompiler::link):
282         (JSC::DFG::JITCompiler::compileFunction):
283         * dfg/DFGOSREntry.cpp:
284         (JSC::DFG::prepareOSREntry):
285         * dfg/DFGSpeculativeJIT.cpp:
286         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
287         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
288         (JSC::DFG::VirtualRegisterAllocationPhase::run):
289         * ftl/FTLLink.cpp:
290         (JSC::FTL::link):
291         * ftl/FTLLowerDFGToLLVM.cpp:
292         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
293         * ftl/FTLOSREntry.cpp:
294         (JSC::FTL::prepareOSREntry):
295         * interpreter/CallFrame.cpp:
296         (JSC::CallFrame::frameExtentInternal):
297         * interpreter/JSStackInlines.h:
298         (JSC::JSStack::pushFrame):
299         * jit/JIT.h:
300         (JSC::JIT::frameRegisterCountFor):
301         * jit/JITOperations.cpp:
302         * llint/LLIntEntrypoint.cpp:
303         (JSC::LLInt::frameRegisterCountFor):
304         * llint/LLIntEntrypoint.h:
305
306 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
307
308         Combine SymbolTable and SharedSymbolTable
309         https://bugs.webkit.org/show_bug.cgi?id=124761
310
311         Reviewed by Geoffrey Garen.
312         
313         SymbolTable was never used directly; we now always used SharedSymbolTable. So, this
314         gets rid of SymbolTable and renames SharedSymbolTable to SymbolTable.
315
316         * bytecode/CodeBlock.h:
317         (JSC::CodeBlock::symbolTable):
318         * bytecode/UnlinkedCodeBlock.h:
319         (JSC::UnlinkedFunctionExecutable::symbolTable):
320         (JSC::UnlinkedCodeBlock::symbolTable):
321         (JSC::UnlinkedCodeBlock::finishCreation):
322         * bytecompiler/BytecodeGenerator.h:
323         (JSC::BytecodeGenerator::symbolTable):
324         * dfg/DFGSpeculativeJIT32_64.cpp:
325         (JSC::DFG::SpeculativeJIT::compile):
326         * dfg/DFGSpeculativeJIT64.cpp:
327         (JSC::DFG::SpeculativeJIT::compile):
328         * dfg/DFGStackLayoutPhase.cpp:
329         (JSC::DFG::StackLayoutPhase::run):
330         * jit/AssemblyHelpers.h:
331         (JSC::AssemblyHelpers::symbolTableFor):
332         * runtime/Arguments.h:
333         (JSC::Arguments::finishCreation):
334         * runtime/Executable.h:
335         (JSC::FunctionExecutable::symbolTable):
336         * runtime/JSActivation.h:
337         (JSC::JSActivation::create):
338         (JSC::JSActivation::JSActivation):
339         (JSC::JSActivation::registersOffset):
340         (JSC::JSActivation::allocationSize):
341         * runtime/JSSymbolTableObject.h:
342         (JSC::JSSymbolTableObject::symbolTable):
343         (JSC::JSSymbolTableObject::JSSymbolTableObject):
344         (JSC::JSSymbolTableObject::finishCreation):
345         * runtime/JSVariableObject.h:
346         (JSC::JSVariableObject::JSVariableObject):
347         * runtime/SymbolTable.cpp:
348         (JSC::SymbolTable::destroy):
349         (JSC::SymbolTable::SymbolTable):
350         * runtime/SymbolTable.h:
351         (JSC::SymbolTable::create):
352         (JSC::SymbolTable::createStructure):
353         * runtime/VM.cpp:
354         (JSC::VM::VM):
355         * runtime/VM.h:
356
357 2013-11-22  Mark Lam  <mark.lam@apple.com>
358
359         Remove residual references to "dynamicGlobalObject".
360         https://bugs.webkit.org/show_bug.cgi?id=124787.
361
362         Reviewed by Filip Pizlo.
363
364         * JavaScriptCore.order:
365         * interpreter/CallFrame.h:
366
367 2013-11-22  Mark Lam  <mark.lam@apple.com>
368
369         Ensure that arity fixups honor stack alignment requirements.
370         https://bugs.webkit.org/show_bug.cgi?id=124756.
371
372         Reviewed by Geoffrey Garen.
373
374         The LLINT and all the JITs rely on CommonSlowPaths::arityCheckFor() to
375         compute the arg count adjustment for the arity fixup. We take advantage
376         of this choke point and introduce the stack alignment padding there in
377         the guise of additional args.
378
379         The only cost of this approach is that the padding will also be
380         initialized to undefined values as if they were args. Since arity fixups
381         are considered a slow path that is rarely taken, this cost is not a
382         concern.
383
384         * runtime/CommonSlowPaths.h:
385         (JSC::CommonSlowPaths::arityCheckFor):
386         * runtime/VM.h:
387         (JSC::VM::isSafeToRecurse):
388
389 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
390
391         BytecodeGenerator should align the stack according to native conventions
392         https://bugs.webkit.org/show_bug.cgi?id=124735
393
394         Reviewed by Mark Lam.
395         
396         Rolling this back in because it actually fixed fast/dom/gc-attribute-node.html, but
397         our infrastructure misleads peole into thinking that fixing a test constitutes
398         breaking it.
399
400         * bytecompiler/BytecodeGenerator.h:
401         (JSC::CallArguments::registerOffset):
402         (JSC::CallArguments::argumentCountIncludingThis):
403         * bytecompiler/NodesCodegen.cpp:
404         (JSC::CallArguments::CallArguments):
405
406 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
407
408         Get rid of CodeBlock::dumpStatistics()
409         https://bugs.webkit.org/show_bug.cgi?id=124762
410
411         Reviewed by Mark Hahnenberg.
412
413         * bytecode/CodeBlock.cpp:
414         (JSC::CodeBlock::CodeBlock):
415         (JSC::CodeBlock::~CodeBlock):
416         * bytecode/CodeBlock.h:
417
418 2013-11-22  Commit Queue  <commit-queue@webkit.org>
419
420         Unreviewed, rolling out r159652.
421         http://trac.webkit.org/changeset/159652
422         https://bugs.webkit.org/show_bug.cgi?id=124778
423
424         broke fast/dom/gc-attribute-node.html (Requested by ap on
425         #webkit).
426
427         * bytecompiler/BytecodeGenerator.cpp:
428         (JSC::BytecodeGenerator::emitCall):
429         (JSC::BytecodeGenerator::emitConstruct):
430         * bytecompiler/BytecodeGenerator.h:
431         (JSC::CallArguments::registerOffset):
432         (JSC::CallArguments::argumentCountIncludingThis):
433         * bytecompiler/NodesCodegen.cpp:
434         (JSC::CallArguments::CallArguments):
435         (JSC::CallArguments::newArgument):
436
437 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
438
439         Fix a typo (requriements->requirements).
440
441         * runtime/StackAlignment.h:
442
443 2013-11-21  Mark Lam  <mark.lam@apple.com>
444
445         CodeBlock::m_numCalleeRegisters need to honor native stack alignment.
446         https://bugs.webkit.org/show_bug.cgi?id=124754.
447
448         Reviewed by Filip Pizlo.
449
450         * bytecompiler/BytecodeGenerator.cpp:
451         (JSC::BytecodeGenerator::newRegister):
452         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
453         (JSC::DFG::VirtualRegisterAllocationPhase::run):
454
455 2013-11-21  Mark Rowe  <mrowe@apple.com>
456
457         <https://webkit.org/b/124702> Stop overriding VALID_ARCHS.
458
459         All modern versions of Xcode set it appropriately for our needs.
460
461         Reviewed by Alexey Proskuryakov.
462
463         * Configurations/Base.xcconfig:
464
465 2013-11-21  Mark Rowe  <mrowe@apple.com>
466
467         <https://webkit.org/b/124701> Fix an error in a few Xcode configuration setting files.
468
469         Reviewed by Alexey Proskuryakov.
470
471         * Configurations/Base.xcconfig:
472
473 2013-11-21  Michael Saboff  <msaboff@apple.com>
474
475         ARM64: Implement push/pop equivalents in LLInt
476         https://bugs.webkit.org/show_bug.cgi?id=124721
477
478         Reviewed by Filip Pizlo.
479
480         Added pushLRAndFP and popLRAndFP that push and pop the link register and frame pointer register.
481         These ops emit code just like what the compiler emits in the prologue and epilogue.  Also changed
482         pushCalleeSaves and popCalleeSaves to use the same store pair and load pair instructions to do
483         the actually pushing and popping.  Finally changed the implementation of push and pop to raise
484         an exception since we don't have (or need) a single register push or pop.
485
486         * llint/LowLevelInterpreter64.asm:
487         * offlineasm/arm64.rb:
488         * offlineasm/instructions.rb:
489
490 2013-11-21  Michael Saboff  <msaboff@apple.com>
491
492         JSC: Removed unused opcodes from offline assembler
493         https://bugs.webkit.org/show_bug.cgi?id=124749
494
495         Reviewed by Mark Hahnenberg.
496
497         Removed the unused, X86 only peekq and pokeq.
498
499         * offlineasm/instructions.rb:
500         * offlineasm/x86.rb:
501
502 2013-11-21  Michael Saboff  <msaboff@apple.com>
503
504         REGRESSION(159395) Fix branch8(…, AbsoluteAddress, …) in ARM64 MacroAssembler
505         https://bugs.webkit.org/show_bug.cgi?id=124688
506
507         Reviewed by Geoffrey Garen.
508
509         Changed handling of the address for the load8() in the branch8(AbsoluteAddress) to be like
510         the rest of the branchXX(AbsoluteAddress) fucntions.
511
512         * assembler/MacroAssemblerARM64.h:
513         (JSC::MacroAssemblerARM64::branch8):
514
515 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
516
517         BytecodeGenerator should align the stack according to native conventions
518         https://bugs.webkit.org/show_bug.cgi?id=124735
519
520         Reviewed by Mark Lam.
521
522         * bytecompiler/BytecodeGenerator.h:
523         (JSC::CallArguments::registerOffset):
524         (JSC::CallArguments::argumentCountIncludingThis):
525         * bytecompiler/NodesCodegen.cpp:
526         (JSC::CallArguments::CallArguments):
527
528 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
529
530         Unreviewed, preemptive build fix.
531
532         * runtime/StackAlignment.h:
533         (JSC::stackAlignmentBytes):
534         (JSC::stackAlignmentRegisters):
535
536 2013-11-21  Filip Pizlo  <fpizlo@apple.com>
537
538         JSC should know what the stack alignment conventions are
539         https://bugs.webkit.org/show_bug.cgi?id=124736
540
541         Reviewed by Mark Lam.
542
543         * GNUmakefile.list.am:
544         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
545         * JavaScriptCore.xcodeproj/project.pbxproj:
546         * runtime/StackAlignment.h: Added.
547         (JSC::stackAlignmentBytes):
548         (JSC::stackAlignmentRegisters):
549
550 2013-11-21  Balazs Kilvady  <kilvadyb@homejinni.com>
551
552         [MIPS] Build fails since r159545.
553         https://bugs.webkit.org/show_bug.cgi?id=124716
554
555         Reviewed by Michael Saboff.
556
557         Add missing implementations in MacroAssembler and LLInt for MIPS.
558
559         * assembler/MIPSAssembler.h:
560         (JSC::MIPSAssembler::sync):
561         * assembler/MacroAssemblerMIPS.h:
562         (JSC::MacroAssemblerMIPS::store8):
563         (JSC::MacroAssemblerMIPS::memoryFence):
564         * offlineasm/mips.rb:
565
566 2013-11-21  Julien Brianceau  <jbriance@cisco.com>
567
568         Fix sh4 build after r159545.
569         https://bugs.webkit.org/show_bug.cgi?id=124713
570
571         Reviewed by Michael Saboff.
572
573         Add missing implementations in macro assembler and LLINT for sh4.
574
575         * assembler/MacroAssemblerSH4.h:
576         (JSC::MacroAssemblerSH4::load8):
577         (JSC::MacroAssemblerSH4::store8):
578         (JSC::MacroAssemblerSH4::memoryFence):
579         * assembler/SH4Assembler.h:
580         (JSC::SH4Assembler::synco):
581         * offlineasm/sh4.rb: Handle "memfence" opcode.
582
583 2013-11-20  Mark Lam  <mark.lam@apple.com>
584
585         Introducing VMEntryScope to update the VM stack limit.
586         https://bugs.webkit.org/show_bug.cgi?id=124634.
587
588         Reviewed by Geoffrey Garen.
589
590         1. Introduced USE(SEPARATE_C_AND_JS_STACK) (defined in Platform.h).
591            Currently, it is hardcoded to use separate C and JS stacks. Once we
592            switch to using the C stack for JS frames, we'll need to fix this to
593            only be enabled when ENABLE(LLINT_C_LOOP).
594
595         2. Stack limits are now tracked in the VM.
596
597            Logically, there are 2 stack limits:
598            a. m_stackLimit for the native C stack, and
599            b. m_jsStackLimit for the JS stack.
600
601            If USE(SEPARATE_C_AND_JS_STACK), then the 2 limits are the same
602            value, and are implemented as 2 fields in a union.
603
604         3. The VM native stackLimit is set as follows:
605            a. Initially, the VM sets it to the limit of the stack of the thread that
606               instantiated the VM. This allows the parser and bytecode generator to
607               run before we enter the VM to execute JS code.
608
609            b. Upon entry into the VM to execute JS code (via one of the
610               Interpreter::execute...() functions), we instantiate a VMEntryScope
611               that sets the VM's stackLimit to the limit of the current thread's
612               stack. The VMEntryScope will automatically restore the previous
613               entryScope and stack limit upon destruction.
614
615            If USE(SEPARATE_C_AND_JS_STACK), the JSStack's methods will set the VM's
616            jsStackLimit whenever it grows or shrinks.
617
618         4. The VM now provides a isSafeToRecurse() function that compares the
619            current stack pointer against its native stackLimit. This subsumes and
620            obsoletes the VMStackBounds class.
621
622         5. The VMEntryScope class also subsumes DynamicGlobalObjectScope for
623            tracking the JSGlobalObject that we last entered the VM with.
624
625         6. Renamed dynamicGlobalObject() to vmEntryGlobalObject() since that is
626            the value that the function retrieves.
627
628         7. Changed JIT and LLINT code to do stack checks against the jsStackLimit
629            in the VM class instead of the JSStack.
630
631         * API/JSBase.cpp:
632         (JSEvaluateScript):
633         (JSCheckScriptSyntax):
634         * API/JSContextRef.cpp:
635         (JSGlobalContextRetain):
636         (JSGlobalContextRelease):
637         * CMakeLists.txt:
638         * GNUmakefile.list.am:
639         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
640         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
641         * JavaScriptCore.xcodeproj/project.pbxproj:
642         * bytecompiler/BytecodeGenerator.cpp:
643         (JSC::BytecodeGenerator::BytecodeGenerator):
644         * bytecompiler/BytecodeGenerator.h:
645         (JSC::BytecodeGenerator::emitNode):
646         (JSC::BytecodeGenerator::emitNodeInConditionContext):
647         * debugger/Debugger.cpp:
648         (JSC::Debugger::detach):
649         (JSC::Debugger::recompileAllJSFunctions):
650         (JSC::Debugger::pauseIfNeeded):
651         * debugger/DebuggerCallFrame.cpp:
652         (JSC::DebuggerCallFrame::vmEntryGlobalObject):
653         * debugger/DebuggerCallFrame.h:
654         * dfg/DFGJITCompiler.cpp:
655         (JSC::DFG::JITCompiler::compileFunction):
656         * dfg/DFGOSREntry.cpp:
657         * ftl/FTLLink.cpp:
658         (JSC::FTL::link):
659         * ftl/FTLOSREntry.cpp:
660         * heap/Heap.cpp:
661         (JSC::Heap::lastChanceToFinalize):
662         (JSC::Heap::deleteAllCompiledCode):
663         * interpreter/CachedCall.h:
664         (JSC::CachedCall::CachedCall):
665         * interpreter/CallFrame.cpp:
666         (JSC::CallFrame::vmEntryGlobalObject):
667         * interpreter/CallFrame.h:
668         * interpreter/Interpreter.cpp:
669         (JSC::unwindCallFrame):
670         (JSC::Interpreter::unwind):
671         (JSC::Interpreter::execute):
672         (JSC::Interpreter::executeCall):
673         (JSC::Interpreter::executeConstruct):
674         (JSC::Interpreter::prepareForRepeatCall):
675         (JSC::Interpreter::debug):
676         * interpreter/JSStack.cpp:
677         (JSC::JSStack::JSStack):
678         (JSC::JSStack::growSlowCase):
679         * interpreter/JSStack.h:
680         * interpreter/JSStackInlines.h:
681         (JSC::JSStack::shrink):
682         (JSC::JSStack::grow):
683         - Moved these inlined functions here from JSStack.h. It reduces some
684           #include dependencies of JSSTack.h which had previously resulted
685           in some EWS bots' unhappiness with this patch.
686         (JSC::JSStack::updateStackLimit):
687         * jit/JIT.cpp:
688         (JSC::JIT::privateCompile):
689         * jit/JITCall.cpp:
690         (JSC::JIT::compileLoadVarargs):
691         * jit/JITCall32_64.cpp:
692         (JSC::JIT::compileLoadVarargs):
693         * jit/JITOperations.cpp:
694         * llint/LLIntSlowPaths.cpp:
695         * llint/LowLevelInterpreter.asm:
696         * parser/Parser.cpp:
697         (JSC::::Parser):
698         * parser/Parser.h:
699         (JSC::Parser::canRecurse):
700         * runtime/CommonSlowPaths.h:
701         * runtime/Completion.cpp:
702         (JSC::evaluate):
703         * runtime/FunctionConstructor.cpp:
704         (JSC::constructFunctionSkippingEvalEnabledCheck):
705         * runtime/JSGlobalObject.cpp:
706         * runtime/JSGlobalObject.h:
707         * runtime/StringRecursionChecker.h:
708         (JSC::StringRecursionChecker::performCheck):
709         * runtime/VM.cpp:
710         (JSC::VM::VM):
711         (JSC::VM::releaseExecutableMemory):
712         (JSC::VM::throwException):
713         * runtime/VM.h:
714         (JSC::VM::addressOfJSStackLimit):
715         (JSC::VM::jsStackLimit):
716         (JSC::VM::setJSStackLimit):
717         (JSC::VM::stackLimit):
718         (JSC::VM::setStackLimit):
719         (JSC::VM::isSafeToRecurse):
720         * runtime/VMEntryScope.cpp: Added.
721         (JSC::VMEntryScope::VMEntryScope):
722         (JSC::VMEntryScope::~VMEntryScope):
723         (JSC::VMEntryScope::requiredCapacity):
724         * runtime/VMEntryScope.h: Added.
725         (JSC::VMEntryScope::globalObject):
726         * runtime/VMStackBounds.h: Removed.
727
728 2013-11-20  Michael Saboff  <msaboff@apple.com>
729
730         [Win] JavaScript JIT crash (with DFG enabled).
731         https://bugs.webkit.org/show_bug.cgi?id=124675
732
733         Reviewed by Geoffrey Garen.
734
735         Similar to the change in r159427, changed linkClosureCall to use regT0/regT1 (payload/tag) for the callee.
736         linkForThunkGenerator already expected the callee in regT0/regT1, but changed the comment to reflect that.
737
738         * jit/Repatch.cpp:
739         (JSC::linkClosureCall):
740         * jit/ThunkGenerators.cpp:
741         (JSC::linkForThunkGenerator):
742
743 2013-11-20  Michael Saboff  <msaboff@apple.com>
744
745         ARMv7: Crash due to use after free of AssemblerBuffer
746         https://bugs.webkit.org/show_bug.cgi?id=124611
747
748         Reviewed by Geoffrey Garen.
749
750         Changed JITFinalizer constructor to take a MacroAssemblerCodePtr instead of a Label.
751         In finalizeFunction(), we use that value instead of calculating it from the label.
752
753         * assembler/MacroAssembler.cpp:
754         * dfg/DFGJITFinalizer.cpp:
755         (JSC::DFG::JITFinalizer::JITFinalizer):
756         (JSC::DFG::JITFinalizer::finalizeFunction):
757         * dfg/DFGJITFinalizer.h:
758
759 2013-11-20  Julien Brianceau  <jbriance@cisco.com>
760
761         Fix CPU(ARM_TRADITIONAL) build after r159545.
762         https://bugs.webkit.org/show_bug.cgi?id=124649
763
764         Reviewed by Michael Saboff.
765
766         Add missing memoryFence, load8 and store8 implementations in macro assembler.
767
768         * assembler/ARMAssembler.h:
769         (JSC::ARMAssembler::dmbSY):
770         * assembler/MacroAssemblerARM.h:
771         (JSC::MacroAssemblerARM::load8):
772         (JSC::MacroAssemblerARM::store8):
773         (JSC::MacroAssemblerARM::memoryFence):
774
775 2013-11-20  Julien Brianceau  <jbriance@cisco.com>
776
777         [armv7][arm64] Speculative build fix after r159545.
778         https://bugs.webkit.org/show_bug.cgi?id=124646
779
780         Reviewed by Filip Pizlo.
781
782         * assembler/ARMv7Assembler.h:
783         * assembler/MacroAssemblerARM64.h:
784         (JSC::MacroAssemblerARM64::memoryFence):
785         * assembler/MacroAssemblerARMv7.h:
786         (JSC::MacroAssemblerARMv7::memoryFence):
787
788 2013-11-19  Ryosuke Niwa  <rniwa@webkit.org>
789
790         Enable HTMLTemplateElement on Mac port
791         https://bugs.webkit.org/show_bug.cgi?id=124637
792
793         Reviewed by Tim Horton.
794
795         * Configurations/FeatureDefines.xcconfig:
796
797 2013-11-19  Filip Pizlo  <fpizlo@apple.com>
798
799         Unreviewed, remove completely bogus assertion.
800
801         * runtime/JSGlobalObject.cpp:
802         (JSC::JSGlobalObject::addFunction):
803
804 2013-11-19  Filip Pizlo  <fpizlo@apple.com>
805
806         Unreviewed, debug build fix.
807
808         * runtime/JSGlobalObject.cpp:
809         (JSC::JSGlobalObject::addFunction):
810
811 2013-11-19  Filip Pizlo  <fpizlo@apple.com>
812
813         Infer constant global variables
814         https://bugs.webkit.org/show_bug.cgi?id=124464
815
816         Reviewed by Sam Weinig.
817         
818         All global variables that are candidates for watchpoint-based constant inference (i.e.
819         not 'const' variables) will now have WatchpointSet's associated with them and those
820         are used to drive the inference by tracking three states of each variable:
821         
822         Uninitialized: the variable's value is Undefined and the WatchpointSet state is
823             ClearWatchpoint.
824         
825         Initialized: the variable's value was set to something (could even be explicitly set
826             to Undefined) and the WatchpointSet state is IsWatching.
827         
828         Invalidated: the variable's value was set to something else (could even be the same
829             thing as before but the point is that a put operation did execute again) and the
830             WatchpointSet is IsInvalidated.
831         
832         If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is
833         IsWatching, then the current value of the variable can be folded in place of the get,
834         and a watchpoint on the variable can be registered.
835         
836         We handle race conditions between the mutator and compiler by mandating that:
837         
838         - The mutator changes the WatchpointSet state after executing the put.
839         
840         - There is no opportunity to install code or call functions between when the mutator
841           executes a put and changes the WatchpointSet state.
842         
843         - The compiler checks the WatchpointSet state prior to reading the value.
844         
845         The concrete algorithm used by the mutator is:
846         
847             1. Store the new value into the variable.
848             --- Execute a store-store fence.
849             2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes
850                IsInvalidated); the IsWatching->IsInvalidated transition may end up firing
851                watchpoints.
852         
853         The concrete algorithm that the compiler uses is:
854         
855             1. Load the state. If it's *not* IsWatching, then give up on constant inference.
856             --- Execute a load-load fence.
857             2. Load the value of the variable and use that for folding, while also registering
858                a DesiredWatchpoint. The various parts of this step can be done in any order.
859         
860         The desired watchpoint registration will fail if the watchpoint set is already
861         invalidated. Now consider the following interesting interleavings:
862         
863         Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store
864             operation, and the variable is folded. The fencing ensures that C2 sees the value
865             stored in M1 - i.e. we fold on the value that will actually be watchpointed. If
866             before the compilation is installed the mutator executes another store then we
867             will be sure that it will be a complete sequence of M1+M2 since compilations get
868             installed at safepoints and never "in the middle" of a put_to_scope. Hence that
869             compilation installation will be invalidated. If the M1+M2 sequence happens after
870             the code is installed, then the code will be invalidated by triggering a jettison.
871         
872         Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is
873             a sensible outcome since if the compiler read the variable's value, it would have
874             seen Undefined.
875         
876         Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold.
877         Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold.
878         Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold.
879         Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold.
880         
881         IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold.
882         
883         IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired
884             watchpoint, and that watchpoint will get invalidated before the code is installed.
885         
886         IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated.
887         IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated.
888         IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated.
889         IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated.
890         
891         Note that this kind of reasoning shows why having the mutator first bump the state and
892         then store the new value would be wrong. If we had done that (M1 = bump state, M2 =
893         execute put) then we could have the following deadly interleavings:
894         
895         Uninitialized->M1->C1->C2->M2:
896         Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the
897             compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the
898             watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a
899             value other than Undefined, and you're toast.
900         
901         You could fix this sort of thing by making the Desired Watchpoints machinery more
902         sophisticated, for example having it track the value that was folded; if the global
903         variable's value was later found to be different then we could invalidate the
904         compilation. You could also fix it by having the compiler also check that the value of
905         the variable is not Undefined before folding. While those all sound great, I decided
906         to instead just use the right interleaving since that results in less code and feels
907         more intuitive.
908         
909         This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic.
910         It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is
911         because 3d-cube takes global variable assignment slow paths very often. Note that this
912         3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is
913         also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue
914         (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due
915         to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the
916         slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS
917         programming often leads to global-var-based idioms and those variables tend to be
918         assigned once, leading to excellent constant folding opportunities in an optimizing
919         JIT. This is very evident in the speed-ups on JSRegress.
920
921         * assembler/ARM64Assembler.h:
922         (JSC::ARM64Assembler::dmbSY):
923         * assembler/ARMv7Assembler.h:
924         (JSC::ARMv7Assembler::dmbSY):
925         * assembler/MacroAssemblerARM64.h:
926         (JSC::MacroAssemblerARM64::memfence):
927         * assembler/MacroAssemblerARMv7.h:
928         (JSC::MacroAssemblerARMv7::load8):
929         (JSC::MacroAssemblerARMv7::memfence):
930         * assembler/MacroAssemblerX86.h:
931         (JSC::MacroAssemblerX86::load8):
932         (JSC::MacroAssemblerX86::store8):
933         * assembler/MacroAssemblerX86Common.h:
934         (JSC::MacroAssemblerX86Common::getUnusedRegister):
935         (JSC::MacroAssemblerX86Common::store8):
936         (JSC::MacroAssemblerX86Common::memoryFence):
937         * assembler/MacroAssemblerX86_64.h:
938         (JSC::MacroAssemblerX86_64::load8):
939         (JSC::MacroAssemblerX86_64::store8):
940         * assembler/X86Assembler.h:
941         (JSC::X86Assembler::movb_rm):
942         (JSC::X86Assembler::movzbl_mr):
943         (JSC::X86Assembler::mfence):
944         (JSC::X86Assembler::X86InstructionFormatter::threeByteOp):
945         (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8):
946         * bytecode/CodeBlock.cpp:
947         (JSC::CodeBlock::CodeBlock):
948         * bytecode/Watchpoint.cpp:
949         (JSC::WatchpointSet::WatchpointSet):
950         (JSC::WatchpointSet::add):
951         (JSC::WatchpointSet::notifyWriteSlow):
952         * bytecode/Watchpoint.h:
953         (JSC::WatchpointSet::state):
954         (JSC::WatchpointSet::isStillValid):
955         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
956         * dfg/DFGAbstractInterpreterInlines.h:
957         (JSC::DFG::::executeEffects):
958         * dfg/DFGByteCodeParser.cpp:
959         (JSC::DFG::ByteCodeParser::getJSConstantForValue):
960         (JSC::DFG::ByteCodeParser::getJSConstant):
961         (JSC::DFG::ByteCodeParser::parseBlock):
962         * dfg/DFGClobberize.h:
963         (JSC::DFG::clobberize):
964         * dfg/DFGFixupPhase.cpp:
965         (JSC::DFG::FixupPhase::fixupNode):
966         * dfg/DFGNode.h:
967         (JSC::DFG::Node::isStronglyProvedConstantIn):
968         (JSC::DFG::Node::hasIdentifierNumberForCheck):
969         (JSC::DFG::Node::hasRegisterPointer):
970         * dfg/DFGNodeFlags.h:
971         * dfg/DFGNodeType.h:
972         * dfg/DFGOperations.cpp:
973         * dfg/DFGOperations.h:
974         * dfg/DFGPredictionPropagationPhase.cpp:
975         (JSC::DFG::PredictionPropagationPhase::propagate):
976         * dfg/DFGSafeToExecute.h:
977         (JSC::DFG::safeToExecute):
978         * dfg/DFGSpeculativeJIT.cpp:
979         (JSC::DFG::SpeculativeJIT::compileNotifyPutGlobalVar):
980         * dfg/DFGSpeculativeJIT.h:
981         (JSC::DFG::SpeculativeJIT::callOperation):
982         * dfg/DFGSpeculativeJIT32_64.cpp:
983         (JSC::DFG::SpeculativeJIT::compile):
984         * dfg/DFGSpeculativeJIT64.cpp:
985         (JSC::DFG::SpeculativeJIT::compile):
986         * ftl/FTLAbbreviatedTypes.h:
987         * ftl/FTLAbbreviations.h:
988         (JSC::FTL::buildFence):
989         * ftl/FTLCapabilities.cpp:
990         (JSC::FTL::canCompile):
991         * ftl/FTLIntrinsicRepository.h:
992         * ftl/FTLLowerDFGToLLVM.cpp:
993         (JSC::FTL::LowerDFGToLLVM::compileNode):
994         (JSC::FTL::LowerDFGToLLVM::compileNotifyPutGlobalVar):
995         * ftl/FTLOutput.h:
996         (JSC::FTL::Output::fence):
997         * jit/JIT.h:
998         * jit/JITOperations.h:
999         * jit/JITPropertyAccess.cpp:
1000         (JSC::JIT::emitPutGlobalVar):
1001         (JSC::JIT::emit_op_put_to_scope):
1002         (JSC::JIT::emitSlow_op_put_to_scope):
1003         * jit/JITPropertyAccess32_64.cpp:
1004         (JSC::JIT::emitPutGlobalVar):
1005         (JSC::JIT::emit_op_put_to_scope):
1006         (JSC::JIT::emitSlow_op_put_to_scope):
1007         * llint/LowLevelInterpreter32_64.asm:
1008         * llint/LowLevelInterpreter64.asm:
1009         * llvm/LLVMAPIFunctions.h:
1010         * offlineasm/arm.rb:
1011         * offlineasm/arm64.rb:
1012         * offlineasm/cloop.rb:
1013         * offlineasm/instructions.rb:
1014         * offlineasm/x86.rb:
1015         * runtime/JSGlobalObject.cpp:
1016         (JSC::JSGlobalObject::addGlobalVar):
1017         (JSC::JSGlobalObject::addFunction):
1018         * runtime/JSGlobalObject.h:
1019         (JSC::JSGlobalObject::addVar):
1020         (JSC::JSGlobalObject::addConst):
1021         * runtime/JSScope.cpp:
1022         (JSC::abstractAccess):
1023         * runtime/JSSymbolTableObject.h:
1024         (JSC::symbolTablePut):
1025         (JSC::symbolTablePutWithAttributes):
1026         * runtime/SymbolTable.cpp:
1027         (JSC::SymbolTableEntry::couldBeWatched):
1028         (JSC::SymbolTableEntry::prepareToWatch):
1029         (JSC::SymbolTableEntry::notifyWriteSlow):
1030         * runtime/SymbolTable.h:
1031
1032 2013-11-19  Michael Saboff  <msaboff@apple.com>
1033
1034         REGRESSION(158384) ARMv7 point checks too restrictive for native calls to traditional ARM code
1035         https://bugs.webkit.org/show_bug.cgi?id=124612
1036
1037         Reviewed by Geoffrey Garen.
1038
1039         Removed ASSERT checks (i.e. lower bit set) for ARM Thumb2 destination addresses related to
1040         calls since we are calling native ARM traditional functions like sin() and cos().
1041
1042         * assembler/ARMv7Assembler.h:
1043         (JSC::ARMv7Assembler::linkCall):
1044         (JSC::ARMv7Assembler::relinkCall):
1045         * assembler/MacroAssemblerCodeRef.h:
1046
1047 2013-11-19  Commit Queue  <commit-queue@webkit.org>
1048
1049         Unreviewed, rolling out r159459.
1050         http://trac.webkit.org/changeset/159459
1051         https://bugs.webkit.org/show_bug.cgi?id=124616
1052
1053         tons of assertions on launch (Requested by thorton on
1054         #webkit).
1055
1056         * API/JSContext.mm:
1057         (-[JSContext setException:]):
1058         (-[JSContext wrapperForObjCObject:]):
1059         (-[JSContext wrapperForJSObject:]):
1060         * API/JSContextRef.cpp:
1061         (JSContextGroupRelease):
1062         (JSGlobalContextRelease):
1063         * API/JSManagedValue.mm:
1064         (-[JSManagedValue initWithValue:]):
1065         (-[JSManagedValue value]):
1066         * API/JSObjectRef.cpp:
1067         (JSObjectIsFunction):
1068         (JSObjectCopyPropertyNames):
1069         * API/JSValue.mm:
1070         (containerValueToObject):
1071         * API/JSWrapperMap.mm:
1072         (tryUnwrapObjcObject):
1073
1074 2013-11-19  Filip Pizlo  <fpizlo@apple.com>
1075
1076         Rename WatchpointSet::notifyWrite() should be renamed to WatchpointSet::fireAll()
1077         https://bugs.webkit.org/show_bug.cgi?id=124609
1078
1079         Rubber stamped by Mark Lam.
1080         
1081         notifyWrite() is a thing that SymbolTable does. WatchpointSet uses that terminology
1082         because it was original designed to match exactly SymbolTable's semantics. But now
1083         it's a confusing term.
1084
1085         * bytecode/Watchpoint.cpp:
1086         (JSC::WatchpointSet::fireAllSlow):
1087         * bytecode/Watchpoint.h:
1088         (JSC::WatchpointSet::fireAll):
1089         (JSC::InlineWatchpointSet::fireAll):
1090         * interpreter/Interpreter.cpp:
1091         (JSC::Interpreter::execute):
1092         * runtime/JSFunction.cpp:
1093         (JSC::JSFunction::put):
1094         (JSC::JSFunction::defineOwnProperty):
1095         * runtime/JSGlobalObject.cpp:
1096         (JSC::JSGlobalObject::haveABadTime):
1097         * runtime/Structure.h:
1098         (JSC::Structure::notifyTransitionFromThisStructure):
1099         * runtime/SymbolTable.cpp:
1100         (JSC::SymbolTableEntry::notifyWriteSlow):
1101
1102 2013-11-18  Michael Saboff  <msaboff@apple.com>
1103
1104         REGRESSION (r159395): Error compiling for ARMv7
1105         https://bugs.webkit.org/show_bug.cgi?id=124552
1106
1107         Reviewed by Geoffrey Garen.
1108
1109         Fixed the implementation of branch8(RelationalCondition cond, AbsoluteAddress address, TrustedImm32 right)
1110         to materialize and use address similar to other ARMv7 branchXX() functions.
1111
1112         * assembler/MacroAssemblerARMv7.h:
1113         (JSC::MacroAssemblerARMv7::branch8):
1114
1115 2013-11-19  Mark Lam  <mark.lam@apple.com>
1116
1117         Add tracking of endColumn for Executables.
1118         https://bugs.webkit.org/show_bug.cgi?id=124245.
1119
1120         Reviewed by Geoffrey Garen.
1121
1122         1. Fixed computation of columns to take into account the startColumn from
1123            <script> tags. Previously, we were only computing the column relative
1124            to the char after the <script> tag. Now, the column number that JSC
1125            computes is always the column number you'll see when viewing the source
1126            in a text editor (assuming the first column position is 1, not 0).
1127
1128         2. Previously, unlinkedExecutables kept the a base-1 startColumn for
1129            ProgramExecutables and EvalExecutables, but uses base-0 columns for
1130            FunctionExecutables. This has been fixed so that they all use base-0
1131            columns. When the executable gets linked, the column is adjusted into
1132            a base-1 value.
1133
1134         3. In the UnlinkedFunctionExecutable, renamed m_functionStartOffset to
1135            m_unlinkedFunctionNameStart because it actually points to the start
1136            column in the name part of the function declaration.
1137
1138            Similarly, renamed m_functionStartColumn to m_unlinkedBodyStartColumn
1139            because it points to the first character in the function body. This is
1140            usually '{' except for functions created from "global code" which
1141            excludes its braces. See FunctionExecutable::fromGlobalCode().
1142
1143                The exclusion of braces for the global code case is needed so that
1144            computed start and end columns will more readily map to what a JS
1145            developer would expect them to be. Otherwise, the first column of the
1146            function source will not be 1 (includes prepended characters added in
1147            constructFunctionSkippingEvalEnabledCheck()).
1148
1149            Also, similarly, a m_unlinkedBodyEndColumn has been added to track the
1150            end column of the UnlinkedFunctionExecutable.
1151
1152         4. For unlinked executables, end column values are either:
1153            a. Relative to the start of the last line if (last line != first line).
1154            b. Relative to the start column position if (last line == first line).
1155
1156            The second case is needed so that we can add an appropriate adjustment
1157            to the end column value (just like we do for the start column) when we
1158            link the executable.
1159
1160         5. This is not new to this patch, but it worth noting that the lineCount
1161            values used through this patch has the following meaning:
1162            - a lineCount of 0 means the source for this code block is on 1 line.
1163            - a lineCount of N means there are N + l lines of source.
1164
1165            This interpretation is janky, but was present before this patch. We can
1166            clean that up later in another patch.
1167
1168
1169         * JavaScriptCore.xcodeproj/project.pbxproj:
1170         - In order to implement WebCore::Internals::parserMetaData(), we need to
1171           move some seemingly unrelated header files from the Project section to
1172           the Private section so that they can be #include'd by the forwarding
1173           CodeBlock.h from WebCore.
1174         * bytecode/CodeBlock.cpp:
1175         (JSC::CodeBlock::sourceCodeForTools):
1176         (JSC::CodeBlock::CodeBlock):
1177         * bytecode/UnlinkedCodeBlock.cpp:
1178         (JSC::generateFunctionCodeBlock):
1179         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1180         - m_isFromGlobalCode is needed to support the exclusion of the open brace /
1181           prepended code for functions created from "global code".
1182         (JSC::UnlinkedFunctionExecutable::link):
1183         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1184         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1185         * bytecode/UnlinkedCodeBlock.h:
1186         (JSC::UnlinkedFunctionExecutable::create):
1187         (JSC::UnlinkedFunctionExecutable::unlinkedFunctionNameStart):
1188         (JSC::UnlinkedFunctionExecutable::unlinkedBodyStartColumn):
1189         (JSC::UnlinkedFunctionExecutable::unlinkedBodyEndColumn):
1190         (JSC::UnlinkedFunctionExecutable::recordParse):
1191         (JSC::UnlinkedCodeBlock::recordParse):
1192         (JSC::UnlinkedCodeBlock::endColumn):
1193         * bytecompiler/NodesCodegen.cpp:
1194         (JSC::FunctionBodyNode::emitBytecode):
1195         * parser/ASTBuilder.h:
1196         (JSC::ASTBuilder::createFunctionBody):
1197         (JSC::ASTBuilder::setFunctionNameStart):
1198         * parser/Lexer.cpp:
1199         (JSC::::shiftLineTerminator):
1200         - Removed an unused SourceCode Lexer<T>::sourceCode() function.
1201         * parser/Lexer.h:
1202         (JSC::Lexer::positionBeforeLastNewline):
1203         (JSC::Lexer::prevTerminator):
1204         - Added tracking of m_positionBeforeLastNewline in the Lexer to enable us
1205           to exclude the close brace / appended code for functions created from "global
1206           code".
1207         * parser/Nodes.cpp:
1208         (JSC::ProgramNode::ProgramNode):
1209         (JSC::ProgramNode::create):
1210         (JSC::EvalNode::EvalNode):
1211         (JSC::EvalNode::create):
1212         (JSC::FunctionBodyNode::FunctionBodyNode):
1213         (JSC::FunctionBodyNode::create):
1214         (JSC::FunctionBodyNode::setEndPosition):
1215         - setEndPosition() is needed to fixed up the end position so that we can
1216           exclude the close brace / appended code for functions created from "global
1217           code".
1218         * parser/Nodes.h:
1219         (JSC::ProgramNode::startColumn):
1220         (JSC::ProgramNode::endColumn):
1221         (JSC::EvalNode::startColumn):
1222         (JSC::EvalNode::endColumn):
1223         (JSC::FunctionBodyNode::setFunctionNameStart):
1224         (JSC::FunctionBodyNode::functionNameStart):
1225         (JSC::FunctionBodyNode::endColumn):
1226         * parser/Parser.cpp:
1227         (JSC::::parseFunctionBody):
1228         (JSC::::parseFunctionInfo):
1229         * parser/Parser.h:
1230         (JSC::Parser::positionBeforeLastNewline):
1231         (JSC::::parse):
1232         - Subtracted 1 from startColumn here to keep the node column values consistently
1233           base-0. See note 2 above.
1234         (JSC::parse):
1235         * parser/SourceProviderCacheItem.h:
1236         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
1237         * parser/SyntaxChecker.h:
1238         (JSC::SyntaxChecker::createFunctionBody):
1239         (JSC::SyntaxChecker::setFunctionNameStart):
1240         * runtime/CodeCache.cpp:
1241         (JSC::CodeCache::getGlobalCodeBlock):
1242         (JSC::CodeCache::getProgramCodeBlock):
1243         (JSC::CodeCache::getEvalCodeBlock):
1244         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
1245         * runtime/CodeCache.h:
1246         * runtime/Executable.cpp:
1247         (JSC::ScriptExecutable::newCodeBlockFor):
1248         (JSC::FunctionExecutable::FunctionExecutable):
1249         (JSC::ProgramExecutable::initializeGlobalProperties):
1250         (JSC::FunctionExecutable::fromGlobalCode):
1251         * runtime/Executable.h:
1252         (JSC::ExecutableBase::isEvalExecutable):
1253         (JSC::ExecutableBase::isProgramExecutable):
1254         (JSC::ScriptExecutable::ScriptExecutable):
1255         (JSC::ScriptExecutable::endColumn):
1256         (JSC::ScriptExecutable::recordParse):
1257         (JSC::FunctionExecutable::create):
1258         (JSC::FunctionExecutable::bodyIncludesBraces):
1259         * runtime/FunctionConstructor.cpp:
1260         (JSC::constructFunctionSkippingEvalEnabledCheck):
1261         * runtime/FunctionPrototype.cpp:
1262         (JSC::insertSemicolonIfNeeded):
1263         (JSC::functionProtoFuncToString):
1264         * runtime/JSGlobalObject.cpp:
1265         (JSC::JSGlobalObject::createProgramCodeBlock):
1266         (JSC::JSGlobalObject::createEvalCodeBlock):
1267
1268 2013-11-19  Dean Jackson  <dino@apple.com>
1269
1270         MarkedSpace::resumeAllocating needs to delay release
1271         https://bugs.webkit.org/show_bug.cgi?id=124596
1272
1273         Reviewed by Geoffrey Garen.
1274
1275         * heap/MarkedSpace.cpp:
1276         (JSC::MarkedSpace::resumeAllocating): Add DelayedReleaseScope protection.
1277
1278 2013-11-19  Mark Hahnenberg  <mhahnenberg@apple.com>
1279
1280         IncrementalSweeper needs to use DelayedReleaseScope too
1281         https://bugs.webkit.org/show_bug.cgi?id=124558
1282
1283         Reviewed by Filip Pizlo.
1284
1285         It does sweeping too, so it needs to use it. Also refactored an
1286         ASSERT that should have caught this sooner.
1287
1288         * heap/DelayedReleaseScope.h:
1289         (JSC::DelayedReleaseScope::isInEffectFor):
1290         * heap/IncrementalSweeper.cpp:
1291         (JSC::IncrementalSweeper::doSweep):
1292         * heap/MarkedBlock.cpp:
1293         (JSC::MarkedBlock::sweep):
1294         * heap/MarkedSpace.cpp:
1295         (JSC::MarkedSpace::sweep):
1296
1297 2013-11-18  Michael Saboff  <msaboff@apple.com>
1298
1299         ARM64 CRASH: Debug builds crash in emitPointerValidation()
1300         https://bugs.webkit.org/show_bug.cgi?id=124545
1301
1302         Reviewed by Filip Pizlo.
1303
1304         Changed emitPointerValidation() to use pushToSave() and popToRestore() as
1305         all macro assemblers have an implementation of these functions.
1306
1307         * jit/ThunkGenerators.cpp:
1308         (JSC::emitPointerValidation):
1309
1310 2013-11-18  Michael Saboff  <msaboff@apple.com>
1311
1312         ARM64: Update getHostCallReturnValue() to use architected frame pointer register
1313         https://bugs.webkit.org/show_bug.cgi?id=124520
1314
1315         Reviewed by Filip Pizlo.
1316
1317         Changed from using the prior JSC specific x25 callframe register to the ARM64
1318         architected x29 (fp) register.  This change should have been done as part of
1319         https://bugs.webkit.org/show_bug.cgi?id=123956.
1320
1321         * jit/JITOperations.cpp:
1322
1323 2013-11-18  Filip Pizlo  <fpizlo@apple.com>
1324
1325         put_to_scope[5] should not point to the structure if it's a variable access, but it should point to the WatchpointSet
1326         https://bugs.webkit.org/show_bug.cgi?id=124539
1327
1328         Reviewed by Mark Hahnenberg.
1329         
1330         This is in preparation for getting put_to_scope to directly invalidate the watchpoint set
1331         on stores, which will allow us to run constant inference on all globals.
1332
1333         * bytecode/CodeBlock.cpp:
1334         (JSC::CodeBlock::CodeBlock):
1335         (JSC::CodeBlock::finalizeUnconditionally):
1336         * bytecode/Instruction.h:
1337         * dfg/DFGByteCodeParser.cpp:
1338         (JSC::DFG::ByteCodeParser::parseBlock):
1339         * runtime/JSScope.cpp:
1340         (JSC::abstractAccess):
1341         (JSC::JSScope::abstractResolve):
1342         * runtime/JSScope.h:
1343         (JSC::ResolveOp::ResolveOp):
1344         * runtime/SymbolTable.h:
1345         (JSC::SymbolTableEntry::watchpointSet):
1346
1347 2013-11-18  Mark Hahnenberg  <mhahnenberg@apple.com>
1348
1349         APIEntryShims need some love
1350         https://bugs.webkit.org/show_bug.cgi?id=124540
1351
1352         Reviewed by Filip Pizlo.
1353
1354         We were missing them in key places which some other hacking revealed. These could have manifested as
1355         race conditions for VMs being used in multithreaded environments.
1356
1357         * API/JSContext.mm:
1358         (-[JSContext setException:]):
1359         (-[JSContext wrapperForObjCObject:]):
1360         (-[JSContext wrapperForJSObject:]):
1361         * API/JSContextRef.cpp:
1362         (JSContextGroupRelease):
1363         (JSGlobalContextRelease):
1364         * API/JSManagedValue.mm:
1365         (-[JSManagedValue initWithValue:]):
1366         (-[JSManagedValue value]):
1367         * API/JSObjectRef.cpp:
1368         (JSObjectIsFunction):
1369         (JSObjectCopyPropertyNames):
1370         * API/JSValue.mm:
1371         (containerValueToObject):
1372         * API/JSWrapperMap.mm:
1373         (tryUnwrapObjcObject):
1374
1375 2013-11-18  Filip Pizlo  <fpizlo@apple.com>
1376
1377         Allow the FTL debug dumps to include the new size field
1378         https://bugs.webkit.org/show_bug.cgi?id=124479
1379
1380         Reviewed by Mark Hahnenberg.
1381
1382         * ftl/FTLStackMaps.cpp:
1383         (JSC::FTL::StackMaps::Location::parse):
1384         (JSC::FTL::StackMaps::Location::dump):
1385         * ftl/FTLStackMaps.h:
1386
1387 2013-11-18  peavo@outlook.com  <peavo@outlook.com>
1388
1389         [Win] Link fails when DFG JIT is enabled.
1390         https://bugs.webkit.org/show_bug.cgi?id=123614
1391
1392         Reviewed by Brent Fulgham.
1393
1394         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Added new files.
1395         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
1396
1397 2013-11-18  Julien Brianceau  <jbriance@cisco.com>
1398
1399         [sh4] Add missing implementation in MacroAssembler to fix build (broken since r159395).
1400         https://bugs.webkit.org/show_bug.cgi?id=124484
1401
1402         Reviewed by Michael Saboff.
1403
1404         * assembler/MacroAssemblerSH4.h:
1405         (JSC::MacroAssemblerSH4::load8):
1406         (JSC::MacroAssemblerSH4::branch8):
1407
1408 2013-11-18  Michael Saboff  <msaboff@apple.com>
1409
1410         ARM64 CRASH: Improper offset in getHostCallReturnValue() to access callerFrame in CallFrame
1411         https://bugs.webkit.org/show_bug.cgi?id=124481
1412
1413         Reviewed by Mark Lam.
1414
1415         Fixed the offset to access CallerFrame in the ARM64 version of getHostCallReturnValue() to be 0
1416         to correspond with the change in CallFrame layout done in r158315.
1417
1418         * jit/JITOperations.cpp:
1419
1420 2013-11-18  Michael Saboff  <msaboff@apple.com>
1421
1422         Crash in virtualForThunkGenerator generated code on ARM64
1423         https://bugs.webkit.org/show_bug.cgi?id=124447
1424
1425         Reviewed by Geoffrey Garen.
1426
1427         The baseline JIT generates slow path call code with the caller in regT0.  The DFG
1428         generates call code with the caller in nonArgGPR0.  The virtualForThunkGenerator
1429         generates code with the caller in nonArgGPR0.  For X86 and X86_64, regT0 and nonArgGPR0
1430         are the same CPU register, eax.  For other platforms this isn't the case.  The same
1431         issue exists for JSVALUE32_64 ports as well, where there also is an issue with the callee
1432         tag registers being regT1 and nonArgGPR1 in the various locations.
1433
1434         Changed nonArgGPR0, nonArgGPR1 and nonArgGPR2 for X86 and X86_64 to not match up with
1435         regT0-2.  Changing these registers will cause a crash on all ports should we have a
1436         similar problem in the future.  Changed the DFG call generating code to use regT0 and
1437         regT1.  Now all slow path call code is generated using regT0 and for JSVALUE32_64 regT1.
1438         Added r12 to X86_64 as a new temp register (regT9) and moved r13 down to regT10.
1439         The new temp register decreases the likelihood of inadvertant register overlap.
1440
1441         * dfg/DFGSpeculativeJIT32_64.cpp:
1442         (JSC::DFG::SpeculativeJIT::emitCall):
1443         * dfg/DFGSpeculativeJIT64.cpp:
1444         (JSC::DFG::SpeculativeJIT::emitCall):
1445         * jit/GPRInfo.h:
1446         (JSC::GPRInfo::toRegister):
1447         (JSC::GPRInfo::toIndex):
1448         * jit/ThunkGenerators.cpp:
1449         (JSC::virtualForThunkGenerator):
1450
1451 2013-11-18  Balazs Kilvady  <kilvadyb@homejinni.com>
1452
1453         Add missing load8/branch8 with AbsoluteAddress parameter to MIPS port.
1454
1455         [MIPS] Build fails since r159395.
1456         https://bugs.webkit.org/show_bug.cgi?id=124491
1457
1458         Reviewed by Michael Saboff.
1459
1460         * assembler/MacroAssemblerMIPS.h:
1461         (JSC::MacroAssemblerMIPS::load8):
1462         (JSC::MacroAssemblerMIPS::branch8):
1463
1464 2013-11-18  Csaba Osztrogonác  <ossy@webkit.org>
1465
1466         REGRESSION(r159351): It made zillion tests assert on !CF platforms
1467         https://bugs.webkit.org/show_bug.cgi?id=124490
1468
1469         Reviewed by Mark Hahnenberg.
1470
1471         * heap/MarkedSpace.cpp:
1472         (JSC::MarkedSpace::sweep):
1473
1474 2013-11-18  Julien Brianceau  <jbriance@cisco.com>
1475
1476         Remove architecture specific code in LowLevelInterpreter.
1477         https://bugs.webkit.org/show_bug.cgi?id=124501
1478
1479         Reviewed by Michael Saboff.
1480
1481         * llint/LowLevelInterpreter.asm: Use generic path instead of sh4 specific code.
1482         * llint/LowLevelInterpreter32_64.asm: Merge sh4/mips path with arm path. The
1483         "move t0, a0" is not needed for arm because t0 == a0 with this architecture.
1484         * offlineasm/sh4.rb: Handle move opcode with pr register.
1485
1486 2013-11-18  Julien Brianceau  <jbriance@cisco.com>
1487
1488         [arm] Add missing implementation in MacroAssembler to fix build (broken since r159395).
1489         https://bugs.webkit.org/show_bug.cgi?id=124488
1490
1491         Reviewed by Zoltan Herczeg.
1492
1493         * assembler/MacroAssemblerARM.h:
1494         (JSC::MacroAssemblerARM::branch8):
1495
1496 2013-11-17  Julien Brianceau  <jbriance@cisco.com>
1497
1498         [sh4] Fix revertJumpReplacementToBranchPtrWithPatch in MacroAssembler.
1499         https://bugs.webkit.org/show_bug.cgi?id=124468
1500
1501         Reviewed by Michael Saboff.
1502
1503         Current implementation of revertJumpReplacementToBranchPtrWithPatch is wrong in
1504         the sh4 MacroAssembler part, leading to random instabilities. This patch fixes it
1505         and also renames the bad-named revertJumpToMove to revertJumpReplacementToBranchPtrWithPatch
1506         in the SH4Assembler.
1507
1508         * assembler/MacroAssemblerSH4.h:
1509         (JSC::MacroAssemblerSH4::revertJumpReplacementToBranchPtrWithPatch):
1510         * assembler/SH4Assembler.h:
1511         (JSC::SH4Assembler::replaceWithJump):
1512         (JSC::SH4Assembler::revertJumpReplacementToBranchPtrWithPatch):
1513
1514 2013-11-16  Filip Pizlo  <fpizlo@apple.com>
1515
1516         Simplify WatchpointSet state tracking
1517         https://bugs.webkit.org/show_bug.cgi?id=124465
1518
1519         Reviewed by Sam Weinig.
1520         
1521         We previously represented the state of watchpoint sets using two booleans. But that
1522         makes it awkward to case over the state.
1523         
1524         We also previously supported a watchpoint set being both watched and invalidated. We
1525         never used that capability, and its presence was just purely confusing.
1526         
1527         This turns the whole thing into an enum.
1528
1529         * assembler/MacroAssemblerARM64.h:
1530         (JSC::MacroAssemblerARM64::branch8):
1531         * assembler/MacroAssemblerARMv7.h:
1532         (JSC::MacroAssemblerARMv7::branch8):
1533         * assembler/MacroAssemblerX86.h:
1534         (JSC::MacroAssemblerX86::branch8):
1535         * assembler/MacroAssemblerX86_64.h:
1536         (JSC::MacroAssemblerX86_64::branch8):
1537         * bytecode/Watchpoint.cpp:
1538         (JSC::WatchpointSet::WatchpointSet):
1539         (JSC::WatchpointSet::add):
1540         (JSC::WatchpointSet::notifyWriteSlow):
1541         (JSC::InlineWatchpointSet::inflateSlow):
1542         * bytecode/Watchpoint.h:
1543         (JSC::WatchpointSet::state):
1544         (JSC::WatchpointSet::isStillValid):
1545         (JSC::WatchpointSet::startWatching):
1546         (JSC::WatchpointSet::notifyWrite):
1547         (JSC::WatchpointSet::addressOfState):
1548         (JSC::InlineWatchpointSet::InlineWatchpointSet):
1549         (JSC::InlineWatchpointSet::hasBeenInvalidated):
1550         (JSC::InlineWatchpointSet::startWatching):
1551         (JSC::InlineWatchpointSet::notifyWrite):
1552         (JSC::InlineWatchpointSet::decodeState):
1553         (JSC::InlineWatchpointSet::encodeState):
1554         * jit/JITPropertyAccess.cpp:
1555         (JSC::JIT::emitVarInjectionCheck):
1556         * jit/JITPropertyAccess32_64.cpp:
1557         (JSC::JIT::emitVarInjectionCheck):
1558         * llint/LowLevelInterpreter.asm:
1559         * llint/LowLevelInterpreter32_64.asm:
1560         * llint/LowLevelInterpreter64.asm:
1561         * runtime/JSFunction.cpp:
1562         (JSC::JSFunction::JSFunction):
1563         * runtime/JSFunctionInlines.h:
1564         (JSC::JSFunction::JSFunction):
1565         * runtime/JSGlobalObject.cpp:
1566         (JSC::JSGlobalObject::JSGlobalObject):
1567         * runtime/Structure.cpp:
1568         (JSC::Structure::Structure):
1569         * runtime/SymbolTable.cpp:
1570         (JSC::SymbolTableEntry::attemptToWatch):
1571         * runtime/SymbolTable.h:
1572
1573 2013-11-16  Filip Pizlo  <fpizlo@apple.com>
1574
1575         FTL should have an explicit notion of bytecode liveness
1576         https://bugs.webkit.org/show_bug.cgi?id=124181
1577
1578         Reviewed by Sam Weinig.
1579         
1580         This makes FTL OSR exit use bytecode liveness analysis to determine which variables
1581         to include values for. The decision of how to get the values of variables is based on
1582         forward propagation of MovHints and SetLocals.
1583         
1584         This fixes a bunch of bugs (like https://bugs.webkit.org/show_bug.cgi?id=124138 but
1585         also others that I noticed when I started writing more targetted tests) and allows us
1586         to remove some sketchy code.
1587
1588         * CMakeLists.txt:
1589         * GNUmakefile.list.am:
1590         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1591         * JavaScriptCore.xcodeproj/project.pbxproj:
1592         * bytecode/BytecodeBasicBlock.h:
1593         * bytecode/BytecodeLivenessAnalysis.cpp:
1594         (JSC::isValidRegisterForLiveness):
1595         (JSC::setForOperand):
1596         (JSC::computeUsesForBytecodeOffset):
1597         (JSC::computeDefsForBytecodeOffset):
1598         (JSC::stepOverInstruction):
1599         (JSC::computeLocalLivenessForBytecodeOffset):
1600         (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
1601         (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
1602         (JSC::getLivenessInfo):
1603         (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
1604         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
1605         * bytecode/BytecodeLivenessAnalysis.h:
1606         * bytecode/BytecodeLivenessAnalysisInlines.h: Added.
1607         (JSC::operandIsAlwaysLive):
1608         (JSC::operandThatIsNotAlwaysLiveIsLive):
1609         (JSC::operandIsLive):
1610         * bytecode/CodeBlock.h:
1611         (JSC::CodeBlock::captureCount):
1612         (JSC::CodeBlock::captureStart):
1613         (JSC::CodeBlock::captureEnd):
1614         * bytecode/CodeOrigin.cpp:
1615         (JSC::InlineCallFrame::dumpInContext):
1616         * bytecode/FullBytecodeLiveness.h: Added.
1617         (JSC::FullBytecodeLiveness::FullBytecodeLiveness):
1618         (JSC::FullBytecodeLiveness::getOut):
1619         (JSC::FullBytecodeLiveness::operandIsLive):
1620         (JSC::FullBytecodeLiveness::getLiveness):
1621         * dfg/DFGAvailability.cpp: Added.
1622         (JSC::DFG::Availability::dump):
1623         (JSC::DFG::Availability::dumpInContext):
1624         * dfg/DFGAvailability.h: Added.
1625         (JSC::DFG::Availability::Availability):
1626         (JSC::DFG::Availability::unavailable):
1627         (JSC::DFG::Availability::withFlush):
1628         (JSC::DFG::Availability::withNode):
1629         (JSC::DFG::Availability::withUnavailableNode):
1630         (JSC::DFG::Availability::nodeIsUndecided):
1631         (JSC::DFG::Availability::nodeIsUnavailable):
1632         (JSC::DFG::Availability::hasNode):
1633         (JSC::DFG::Availability::node):
1634         (JSC::DFG::Availability::flushedAt):
1635         (JSC::DFG::Availability::operator!):
1636         (JSC::DFG::Availability::operator==):
1637         (JSC::DFG::Availability::merge):
1638         (JSC::DFG::Availability::mergeNodes):
1639         (JSC::DFG::Availability::unavailableMarker):
1640         * dfg/DFGBasicBlock.h:
1641         * dfg/DFGByteCodeParser.cpp:
1642         (JSC::DFG::ByteCodeParser::parseBlock):
1643         * dfg/DFGDisassembler.cpp:
1644         (JSC::DFG::Disassembler::Disassembler):
1645         * dfg/DFGFlushFormat.cpp:
1646         (WTF::printInternal):
1647         * dfg/DFGFlushFormat.h:
1648         (JSC::DFG::resultFor):
1649         (JSC::DFG::useKindFor):
1650         (JSC::DFG::dataFormatFor):
1651         * dfg/DFGFlushedAt.cpp:
1652         (JSC::DFG::FlushedAt::dump):
1653         * dfg/DFGFlushedAt.h:
1654         (JSC::DFG::FlushedAt::FlushedAt):
1655         (JSC::DFG::FlushedAt::merge):
1656         * dfg/DFGGraph.cpp:
1657         (JSC::DFG::Graph::dump):
1658         (JSC::DFG::Graph::livenessFor):
1659         (JSC::DFG::Graph::isLiveInBytecode):
1660         * dfg/DFGGraph.h:
1661         (JSC::DFG::Graph::baselineCodeBlockFor):
1662         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1663         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
1664         * dfg/DFGOSRAvailabilityAnalysisPhase.h:
1665         * dfg/DFGPlan.cpp:
1666         (JSC::DFG::Plan::compileInThreadImpl):
1667         * dfg/DFGResurrectionForValidationPhase.cpp: Added.
1668         (JSC::DFG::ResurrectionForValidationPhase::ResurrectionForValidationPhase):
1669         (JSC::DFG::ResurrectionForValidationPhase::run):
1670         (JSC::DFG::performResurrectionForValidation):
1671         * dfg/DFGResurrectionForValidationPhase.h: Added.
1672         * dfg/DFGSSAConversionPhase.cpp:
1673         (JSC::DFG::SSAConversionPhase::run):
1674         * dfg/DFGValueSource.h:
1675         (JSC::DFG::ValueSource::forFlushFormat):
1676         * dfg/DFGVariableAccessData.h:
1677         * ftl/FTLExitValue.cpp:
1678         (JSC::FTL::ExitValue::dumpInContext):
1679         * ftl/FTLInlineCacheSize.cpp:
1680         (JSC::FTL::sizeOfGetById):
1681         * ftl/FTLLocation.cpp:
1682         (JSC::FTL::Location::gpr):
1683         (JSC::FTL::Location::fpr):
1684         (JSC::FTL::Location::directGPR):
1685         * ftl/FTLLowerDFGToLLVM.cpp:
1686         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
1687         (JSC::FTL::LowerDFGToLLVM::compileBlock):
1688         (JSC::FTL::LowerDFGToLLVM::compileNode):
1689         (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
1690         (JSC::FTL::LowerDFGToLLVM::compileZombieHint):
1691         (JSC::FTL::LowerDFGToLLVM::compilePutById):
1692         (JSC::FTL::LowerDFGToLLVM::compileInvalidationPoint):
1693         (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
1694         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1695         (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
1696         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1697         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
1698         (JSC::FTL::LowerDFGToLLVM::observeMovHint):
1699         * ftl/FTLOutput.h:
1700         (JSC::FTL::Output::alloca):
1701         * ftl/FTLValueSource.cpp: Removed.
1702         * ftl/FTLValueSource.h: Removed.
1703         * llvm/LLVMAPIFunctions.h:
1704         * runtime/DumpContext.cpp:
1705         (JSC::DumpContext::DumpContext):
1706         * runtime/DumpContext.h:
1707         * runtime/Options.h:
1708         * runtime/SymbolTable.h:
1709         (JSC::SharedSymbolTable::captureStart):
1710         (JSC::SharedSymbolTable::captureEnd):
1711         (JSC::SharedSymbolTable::captureCount):
1712
1713 2013-11-16  Filip Pizlo  <fpizlo@apple.com>
1714
1715         Fix indentation of JSActivation.h.
1716
1717         Rubber stamped by Mark Hahnenberg.
1718
1719         * runtime/JSActivation.h:
1720
1721 2013-11-16  Filip Pizlo  <fpizlo@apple.com>
1722
1723         Fix indentation of JSVariableObject.h.
1724
1725         Rubber stamped by Mark Hahnenberg.
1726         
1727         I'm about to do some damage to this file. I wanted to give it some sanity first.
1728
1729         * runtime/JSVariableObject.h:
1730
1731 2013-11-16  Julien Brianceau  <jbriance@cisco.com>
1732
1733         [sh4] Fix build (broken since r159346).
1734         https://bugs.webkit.org/show_bug.cgi?id=124455
1735
1736         Reviewed by Oliver Hunt.
1737
1738         Fix LLINT implementation for sh4 architecture to handle properly load and store operations with pr register.
1739
1740         * offlineasm/sh4.rb:
1741
1742 2013-11-15  Alexey Proskuryakov  <ap@apple.com>
1743
1744         Support exporting symmetric keys as JWK
1745         https://bugs.webkit.org/show_bug.cgi?id=124442
1746
1747         Reviewed by Sam Weinig.
1748
1749         * runtime/JSONObject.h: Export JSONStringify.
1750
1751 2013-11-15  peavo@outlook.com  <peavo@outlook.com>
1752
1753         [Win] JavaScript crashes on 64-bit with JIT enabled.
1754         https://bugs.webkit.org/show_bug.cgi?id=124409
1755
1756         Reviewed by Michael Saboff.
1757
1758         These are issues found with JIT on 64-bit:
1759         - The registers rsi and rdi in callToJavaScript needs to be saved and restored. This is required by the Windows 64-bit ABI.
1760         - The getHostCallReturnValue function needs to be updated according to it's GCC counterpart.
1761         - The poke argument offset needs to be 20h, because Windows 64-bit ABI requires stack space allocated for the 4 argument registers.
1762
1763         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Re-added JITStubsMSVC64.asm to project.
1764         * jit/CCallHelpers.h: Set poke argument offset.
1765         (JSC::CCallHelpers::setupArguments): Compile fix, added needed method.
1766         * jit/JITStubsMSVC64.asm: Save and restore registers rsi and rdi.
1767                                   Update getHostCallReturnValue according to the GCC version.
1768
1769 2013-11-14  David Farler  <dfarler@apple.com>
1770
1771         Copy ASAN flag settings to WebCore and JavaScriptCore intermediate build tools
1772         https://bugs.webkit.org/show_bug.cgi?id=124362
1773
1774         Reviewed by David Kilzer.
1775
1776         * Configurations/ToolExecutable.xcconfig:
1777         Use ASAN_C*FLAGS.
1778
1779 2013-11-15  Mark Hahnenberg  <mhahnenberg@apple.com>
1780
1781         Remove JSChunk
1782         https://bugs.webkit.org/show_bug.cgi?id=124435
1783
1784         Reviewed by Geoffrey Garen.
1785
1786         It's empty and has been since it was added 3 years ago.
1787
1788         * CMakeLists.txt:
1789         * runtime/JSChunk.cpp: Removed.
1790         * runtime/JSChunk.h: Removed.
1791
1792 2013-11-15  Mark Hahnenberg  <mhahnenberg@apple.com>
1793
1794         Remove VTableSpectrum
1795         https://bugs.webkit.org/show_bug.cgi?id=124427
1796
1797         Reviewed by Filip Pizlo.
1798
1799         * CMakeLists.txt:
1800         * GNUmakefile.list.am:
1801         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1802         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1803         * JavaScriptCore.xcodeproj/project.pbxproj:
1804         * heap/Heap.cpp:
1805         (JSC::Heap::lastChanceToFinalize):
1806         * heap/Heap.h:
1807         * heap/MarkedBlock.cpp:
1808         (JSC::MarkedBlock::callDestructor):
1809         * heap/SlotVisitor.cpp:
1810         (JSC::visitChildren):
1811         * heap/SlotVisitor.h:
1812         * heap/VTableSpectrum.cpp: Removed.
1813         * heap/VTableSpectrum.h: Removed.
1814
1815 2013-11-14  Mark Hahnenberg  <mhahnenberg@apple.com>
1816
1817         -dealloc callbacks from wrapped Objective-C objects can happen at bad times
1818         https://bugs.webkit.org/show_bug.cgi?id=123821
1819
1820         Reviewed by Darin Adler.
1821
1822         Currently with the JSC Obj-C API, JS wrappers for client Obj-C objects retain their associated Obj-C 
1823         object. When they are swept, they release their Obj-C objects which can trigger a call to that 
1824         object's -dealloc method. These -dealloc methods can then call back into the same VM, which is not 
1825         allowed during sweeping or VM shutdown.
1826
1827         We can handle this case by creating our own pool of Obj-C objects to be released when it is safe to do so.
1828         This is accomplished by using DelayedReleaseScope, an RAII-style object that will retain all objects
1829         that are unsafe to release until the end of the DelayedReleaseScope.
1830
1831         * API/APIShims.h:
1832         (JSC::APICallbackShim::APICallbackShim):
1833         (JSC::APICallbackShim::vmForDropAllLocks):
1834         (JSC::APICallbackShim::execForDropAllLocks):
1835         * API/JSAPIWrapperObject.mm:
1836         (JSAPIWrapperObjectHandleOwner::finalize):
1837         * API/ObjCCallbackFunction.mm:
1838         (JSC::ObjCCallbackFunctionImpl::destroy):
1839         (JSC::ObjCCallbackFunction::destroy):
1840         * API/tests/testapi.mm:
1841         (-[TinyDOMNode initWithVirtualMachine:]):
1842         (-[TinyDOMNode dealloc]):
1843         (-[TinyDOMNode appendChild:]):
1844         (-[TinyDOMNode removeChildAtIndex:]):
1845         (-[EvilAllocationObject initWithContext:]):
1846         (-[EvilAllocationObject dealloc]):
1847         (-[EvilAllocationObject doEvilThingsWithContext:]):
1848         * JavaScriptCore.xcodeproj/project.pbxproj:
1849         * heap/DelayedReleaseScope.h: Added.
1850         (JSC::DelayedReleaseScope::DelayedReleaseScope):
1851         (JSC::DelayedReleaseScope::~DelayedReleaseScope):
1852         (JSC::DelayedReleaseScope::releaseSoon):
1853         (JSC::MarkedSpace::releaseSoon):
1854         * heap/Heap.cpp:
1855         (JSC::Heap::collectAllGarbage):
1856         * heap/Heap.h:
1857         (JSC::Heap::releaseSoon):
1858         * heap/MarkedAllocator.cpp:
1859         (JSC::MarkedAllocator::allocateSlowCase):
1860         * heap/MarkedSpace.cpp:
1861         (JSC::MarkedSpace::MarkedSpace):
1862         (JSC::MarkedSpace::lastChanceToFinalize):
1863         (JSC::MarkedSpace::sweep):
1864         * heap/MarkedSpace.h:
1865
1866 2013-11-15  Michael Saboff  <msaboff@apple.com>
1867
1868         REGRESSION (r158586): callToJavaScript needs to save return PC to Sentinel frame
1869         https://bugs.webkit.org/show_bug.cgi?id=124420
1870
1871         Reviewed by Filip Pizlo.
1872
1873         Save the return PC into the sentinel frame.
1874
1875         * jit/JITStubsMSVC64.asm:
1876         * jit/JITStubsX86.h:
1877         * llint/LowLevelInterpreter32_64.asm:
1878         * llint/LowLevelInterpreter64.asm:
1879
1880 2013-11-14  Oliver Hunt  <oliver@apple.com>
1881
1882         Make CLoop easier to build, and make it work
1883         https://bugs.webkit.org/show_bug.cgi?id=124359
1884
1885         Reviewed by Geoffrey Garen.
1886
1887         Add --cloop to build-jsc, build-webkit and friends.
1888
1889         Also make CLoop build and work again - This meant adding a
1890         couple of missing ENABLE(DFG_JIT) blocks, and fixing a few 
1891         other references.
1892
1893         * Configurations/FeatureDefines.xcconfig:
1894         * bytecode/BytecodeLivenessAnalysis.cpp:
1895         (JSC::computeUsesForBytecodeOffset):
1896         (JSC::computeDefsForBytecodeOffset):
1897         * bytecode/DFGExitProfile.cpp:
1898         * dfg/DFGCapabilities.cpp:
1899         * dfg/DFGCompilationKey.cpp:
1900         * dfg/DFGCompilationMode.cpp:
1901         * jit/JITExceptions.cpp:
1902         (JSC::genericUnwind):
1903
1904 2013-11-14  Michael Saboff  <msaboff@apple.com>
1905
1906         REGRESSION (r159276): Fix lots of crashes for arm_traditional architecture.
1907         https://bugs.webkit.org/show_bug.cgi?id=124365
1908
1909         Reviewed by Oliver Hunt.
1910
1911         Crashes were caused by a mixup between regular registers and temporary registers in ARM_EXTRA_GPRS.
1912
1913         * llint/LowLevelInterpreter32_64.asm: Warning, t3 != a3. It's safer to use an implementation using aX
1914         registers like the MIPS one for cCallX macros.
1915         * offlineasm/arm.rb: Rearrange ARM_EXTRA_GPRS according to the new register distribution in LLINT.
1916
1917 2013-11-14  Michael Saboff  <msaboff@apple.com>
1918
1919         REGRESSION (r159276): rbp register overwritten in Win 64 version of callToJavascript stub
1920         https://bugs.webkit.org/show_bug.cgi?id=124361
1921
1922         Reviewed by Oliver Hunt.
1923
1924         Swapped operand ordering to: mov rax, rbp
1925
1926         * jit/JITStubsMSVC64.asm:
1927
1928 2013-11-14  Julien Brianceau  <jbriance@cisco.com>
1929
1930         REGRESSION (r159276): Fix lots of crashes for sh4 architecture.
1931         https://bugs.webkit.org/show_bug.cgi?id=124347
1932
1933         Reviewed by Michael Saboff.
1934
1935         Since r159276, we have (t4 == a0 == r4) and (t5 == a1 == r5) in LLINT for sh4.
1936         This leads to argument register trampling in cCallX macros, especially with cCall2
1937         macro when arg1 == t4.
1938
1939         * llint/LowLevelInterpreter32_64.asm: Use a new "setargs" pseudo-op to setup arguments for sh4.
1940         * offlineasm/instructions.rb:
1941         * offlineasm/sh4.rb: Lower "setargs" pseudo-op to setup argument registers and prevent register trampling issues.
1942
1943 2013-11-14  Julien Brianceau  <jbriance@cisco.com>
1944
1945         Fix build for sh4 architectures (broken since r159276).
1946         https://bugs.webkit.org/show_bug.cgi?id=124344
1947
1948         Reviewed by Csaba Osztrogonác.
1949
1950         * offlineasm/sh4.rb: There is no fp alias for r14 register for sh4.
1951
1952 2013-11-13  Michael Saboff  <msaboff@apple.com>
1953
1954         Change callToJavaScript thunk into an offline assembled stub
1955         https://bugs.webkit.org/show_bug.cgi?id=124251
1956
1957         Reviewed by Geoffrey Garen.
1958
1959         Changed callToJavaScript and throwNotCaught into stubs generated by the offline assembler.
1960         Added popCalleeSaves and pushCalleeSaves pseudo ops to the offline assembler to handle
1961         the saving and restoring of callee save registers.  Fixed callFrameRegister differences
1962         between arm traditional (r11) and arm Thumb2 (r7) in GPRInfo.h.  Also fixed implementation
1963         of pop & push in arm.rb.
1964
1965         Since the offline assembler and therefore the LLInt don't work on Windows, the Windows stubs
1966         are handled as inline assembly in JITStubsX86.h and JITStubsMSVC64.asm.
1967
1968         * dfg/DFGDriver.cpp:
1969         (JSC::DFG::compileImpl):
1970         * jit/GPRInfo.h:
1971         (JSC::GPRInfo::toIndex):
1972         (JSC::GPRInfo::debugName):
1973         * jit/JITCode.cpp:
1974         (JSC::JITCode::execute):
1975         * jit/JITExceptions.cpp:
1976         (JSC::genericUnwind):
1977         * jit/JITStubs.h:
1978         * jit/JITStubsMSVC64.asm:
1979         * jit/JITStubsX86.h:
1980         * jit/ThunkGenerators.cpp:
1981         * jit/ThunkGenerators.h:
1982         * llint/LLIntThunks.h:
1983         * llint/LowLevelInterpreter.asm:
1984         * llint/LowLevelInterpreter32_64.asm:
1985         * llint/LowLevelInterpreter64.asm:
1986         * offlineasm/arm.rb:
1987         * offlineasm/arm64.rb:
1988         * offlineasm/instructions.rb:
1989         * offlineasm/mips.rb:
1990         * offlineasm/registers.rb:
1991         * offlineasm/sh4.rb:
1992         * offlineasm/x86.rb:
1993         * runtime/VM.cpp:
1994         (JSC::VM::VM):
1995         * runtime/VM.h:
1996
1997 2013-11-13  Andy Estes  <aestes@apple.com>
1998
1999         Fix the ARM64 build after recent JavaScriptCore changes
2000         https://bugs.webkit.org/show_bug.cgi?id=124315
2001
2002         Reviewed by Michael Saboff.
2003
2004         Based on patches by myself, Filip Pizlo, Benjamin Poulain, and Michael Saboff.
2005
2006         * Configurations/JavaScriptCore.xcconfig: Hid the symbol for
2007         std::bad_function_call.
2008         * JavaScriptCore.xcodeproj/project.pbxproj: Marked
2009         MacroAssemblerARM64.h and ARM64Assembler.h as Private headers.
2010         * assembler/ARM64Assembler.h:
2011         (JSC::ARM64Assembler::executableOffsetFor):
2012         * assembler/MacroAssemblerARM64.h: Removed ARM64's executableCopy(),
2013         which was removed from other assembler backends in r157690.
2014         (JSC::MacroAssemblerARM64::shouldBlindForSpecificArch): Added.
2015         (JSC::MacroAssemblerARM64::lshift64): Added.
2016         (JSC::MacroAssemblerARM64::mul64): Added.
2017         (JSC::MacroAssemblerARM64::rshift64): Added.
2018         (JSC::MacroAssemblerARM64::convertInt64ToDouble): Added.
2019         (JSC::MacroAssemblerARM64::branchMul64): Added.
2020         (JSC::MacroAssemblerARM64::branchNeg64): Added.
2021         (JSC::MacroAssemblerARM64::scratchRegisterForBlinding): Added.
2022         * dfg/DFGSpeculativeJIT.cpp:
2023         (JSC::DFG::SpeculativeJIT::compileArithDiv): Changed
2024         SpeculateIntegerOperand to SpeculateInt32Operand,
2025         nodeCanIgnoreNegativeZero() to bytecodeCanIgnoreNegativeZero(), and
2026         nodeUsedAsNumber() to bytecodeUsesAsNumber().
2027         (JSC::DFG::SpeculativeJIT::compileArithMod): Changed
2028         nodeCanIgnoreNegativeZero() to bytecodeCanIgnoreNegativeZero().
2029
2030 2013-11-13  Oliver Hunt  <oliver@apple.com>
2031
2032         Fix debug build.
2033
2034         * parser/Parser.cpp:
2035
2036 2013-11-13  Tim Horton  <timothy_horton@apple.com>
2037
2038         r159210 added a period where there previously wasn't one, breaking >100 tests
2039
2040         Rubber-stamped by Oliver Hunt.
2041
2042         * parser/Parser.cpp:
2043         (JSC::::logError):
2044         Remove the extra period.
2045
2046 2013-11-13  Oliver Hunt  <oliver@apple.com>
2047
2048         REGRESSION (r158014): Many webpages throw stack overflow exceptions on iOS (because Parser::parseMemberExpression uses ~130K more stack)
2049         https://bugs.webkit.org/show_bug.cgi?id=124177
2050
2051         Reviewed by Michael Saboff.
2052
2053         This patch pushes error handling into NEVER_INLINE functions to perform
2054         the actual error message construction.  This dramatically reduces the
2055         stack usage of the Parser.  For the large functions (such as parseMemberExpression)
2056         the improvement is on the order of 2.5x reduction in stack usage.  For
2057         smaller functions the reduction is in the order of 5-6x.
2058
2059         * parser/Parser.cpp:
2060         (JSC::::logError):
2061         * parser/Parser.h:
2062
2063 2013-11-13  Julien Brianceau  <jbriance@cisco.com>
2064
2065         [sh4] Protect repatchCompact from flushConstantPool.
2066         https://bugs.webkit.org/show_bug.cgi?id=124278
2067
2068         Reviewed by Michael Saboff.
2069
2070         Random crashes may occur with sh4 architecture, when a flushConstantPool occurs in
2071         movlMemRegCompact. As in this case a branch opcode and the constant pool are put
2072         before the movlMemRegCompact, the branch itself is patched when calling repatchCompact
2073         instead of the mov instruction, which is really bad.
2074
2075         * assembler/SH4Assembler.h:
2076         (JSC::SH4Assembler::repatchCompact): Handle this specific case and add an ASSERT.
2077
2078 2013-11-12  Alexey Proskuryakov  <ap@apple.com>
2079
2080         Disable WebCrypto on Mountain Lion
2081         https://bugs.webkit.org/show_bug.cgi?id=124261
2082
2083         Rubber-stamped by Sam Weinig.
2084
2085         * Configurations/FeatureDefines.xcconfig:
2086
2087 2013-11-12  Julien Brianceau  <jbriance@cisco.com>
2088
2089         [sh4] Fix load32WithUnalignedHalfWords function in baseline JIT.
2090         https://bugs.webkit.org/show_bug.cgi?id=124233
2091
2092         Reviewed by Michael Saboff.
2093
2094         * assembler/MacroAssemblerSH4.h:
2095         (JSC::MacroAssemblerSH4::load32WithUnalignedHalfWords): Do not claim scratch register too early.
2096         Test already covered by fast/regex/pcre-test-1.
2097
2098 2013-11-12  Filip Pizlo  <fpizlo@apple.com>
2099
2100         Liveness analysis should take less memory in CodeBlock when it is unused
2101         https://bugs.webkit.org/show_bug.cgi?id=124225
2102
2103         Reviewed by Mark Hahnenberg.
2104         
2105         Basically, I turned CodeBlock::m_livenessAnalysis into a pointer that is null by
2106         default.
2107
2108         * bytecode/BytecodeLivenessAnalysis.cpp:
2109         (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
2110         (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
2111         (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
2112         (JSC::BytecodeLivenessAnalysis::dumpResults):
2113         (JSC::BytecodeLivenessAnalysis::compute):
2114         * bytecode/BytecodeLivenessAnalysis.h:
2115         * bytecode/CodeBlock.cpp:
2116         (JSC::CodeBlock::CodeBlock):
2117         * bytecode/CodeBlock.h:
2118         (JSC::CodeBlock::livenessAnalysis):
2119
2120 2013-11-11  Oliver Hunt  <oliver@apple.com>
2121
2122         Support unprefixed deconstructing assignment
2123         https://bugs.webkit.org/show_bug.cgi?id=124172
2124
2125         Reviewed by Mark Lam.
2126
2127         Add support for unprefixed descontructive assignment.
2128
2129         Happily non-reference types on the left hand side of an assignment
2130         are a runtime error, so we're able to defer validation of the binding
2131         pattern to codegen time when we're already doing a lot more work.
2132
2133         We're also able to predicate our attempt to parse on the existence of
2134         '[' or '{' as they are not as common as other constructs. 
2135
2136         * bytecompiler/NodesCodegen.cpp:
2137         (JSC::ArrayPatternNode::emitDirectBinding):
2138         * parser/ASTBuilder.h:
2139         * parser/Parser.cpp:
2140         (JSC::::createBindingPattern):
2141         (JSC::::tryParseDeconstructionPatternExpression):
2142         (JSC::::parseDeconstructionPattern):
2143         (JSC::::parseForStatement):
2144         (JSC::::parseAssignmentExpression):
2145         * parser/Parser.h:
2146         (JSC::Parser::createSavePoint):
2147         (JSC::Parser::restoreSavePoint):
2148         * parser/SyntaxChecker.h:
2149
2150 2013-11-12  Andy Estes  <aestes@apple.com>
2151
2152         Run JavaScriptCore Objective-C API tests on all supported platforms
2153         https://bugs.webkit.org/show_bug.cgi?id=124214
2154
2155         Reviewed by Mark Hahnenberg.
2156
2157         Now that we support the API on iOS and on OS X 10.8, there's no reason
2158         to limit the tests to OS X 10.9 (or greater).
2159
2160         * API/tests/CurrentThisInsideBlockGetterTest.h:
2161         * API/tests/CurrentThisInsideBlockGetterTest.mm:
2162         * API/tests/testapi.mm:
2163
2164 2013-08-02  Mark Hahnenberg  <mhahnenberg@apple.com>
2165
2166         CodeBlocks should be able to determine bytecode liveness
2167         https://bugs.webkit.org/show_bug.cgi?id=118546
2168
2169         Reviewed by Filip Pizlo.
2170
2171         This will simplify some things in the DFG related to OSR exits and determining 
2172         which bytecode variables are live at which points during execution. It will
2173         also be useful for making our conservative GC scan more precise. Currently it 
2174         doesn't properly account for liveness while the DFG is running, so it will be 
2175         off by default behing a runtime Options flag.
2176
2177         * JavaScriptCore.xcodeproj/project.pbxproj:
2178         * bytecode/BytecodeBasicBlock.cpp: Added.
2179         (JSC::isBranch): Used to determine the end of basic blocks.
2180         (JSC::isUnconditionalBranch): Used to determine when a branch at the end of a 
2181         basic block can't possibly fall through to the next basic block in program order.
2182         (JSC::isTerminal): Also used to detect the end of a block.
2183         (JSC::isThrow):
2184         (JSC::isJumpTarget): Used to correctly separate basic blocks. Any jump destination 
2185         must be the head of its own basic block.
2186         (JSC::linkBlocks): Links two blocks together in a bi-direcitonal fashion.
2187         (JSC::computeBytecodeBasicBlocks): Creates a set of basic blocks given a particular 
2188         CodeBlock and links them together.
2189         * bytecode/BytecodeBasicBlock.h: Added.
2190         (JSC::BytecodeBasicBlock::isEntryBlock): Entry blocks are a special basic blocks 
2191         that indicate the beginning of the function.
2192         (JSC::BytecodeBasicBlock::isExitBlock): Exit blocks are a special basic block that 
2193         all blocks that exit the function have as a successor. Entry and exit blocks allows 
2194         the various code paths to be more regular.
2195         (JSC::BytecodeBasicBlock::leaderBytecodeOffset): The leader bytecode offset is the 
2196         bytecode offset of the first instruction in the block.
2197         (JSC::BytecodeBasicBlock::totalBytecodeLength): The total length of all the bytecodes 
2198         in this block.
2199         (JSC::BytecodeBasicBlock::bytecodeOffsets): The bytecode offsets in this particular 
2200         basic block. This Vector allows us to iterate over the bytecodes in reverse order 
2201         which wouldn't be possible normally since they are of variable size.
2202         (JSC::BytecodeBasicBlock::addPredecessor): Links a block to a specified predecessor. 
2203         Only creates one direction of the link.
2204         (JSC::BytecodeBasicBlock::addSuccessor): Same as addPredecessor, but for successors.
2205         (JSC::BytecodeBasicBlock::predecessors): Getter for predecessors.
2206         (JSC::BytecodeBasicBlock::successors): Getter for successors.
2207         (JSC::BytecodeBasicBlock::in): Getter for the liveness info at the head of the block.
2208         (JSC::BytecodeBasicBlock::out): Getter for the liveness info at  the tail of the block.
2209         (JSC::BytecodeBasicBlock::BytecodeBasicBlock):
2210         (JSC::BytecodeBasicBlock::addBytecodeLength): When creating basic blocks we call 
2211         this function when we want to add the next bytecode in program order to this block.
2212         * bytecode/BytecodeLivenessAnalysis.cpp: Added.
2213         (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
2214         (JSC::numberOfCapturedVariables): Convenience wrapper. Returns the
2215         number of captured variables for a particular CodeBlock, or 0 if 
2216         the CodeBlock has no SymbolTable.
2217         (JSC::captureStart): Ditto, but for captureStart().
2218         (JSC::captureEnd): Ditto, but for captureEnd().
2219         (JSC::isValidRegisterForLiveness): Returns true if the liveness analysis should 
2220         track the liveness of a particular operand. We ignore constants, arguments, and 
2221         captured variables. We ignore arguments because they're live for the duration of 
2222         a function call. We ignore captured variables because we also treat them as live 
2223         for the duration of the function. This could probably be improved to be more precise, 
2224         but it didn't seem worth it for now.
2225         (JSC::setForOperand): Convenience wrapper that sets the bit in the provided bit 
2226         vector for the provided operand. It handles skipping over captured variables.
2227         (JSC::computeUsesForBytecodeOffset): Computes which operands are used by a particular bytecode.
2228         (JSC::computeDefsForBytecodeOffset): Computes which operands are defined by a particular 
2229         bytecode. Typically this is just the left-most operand.
2230         (JSC::findBasicBlockWithLeaderOffset): 
2231         (JSC::findBasicBlockForBytecodeOffset): Scans over basic blocks to find the block 
2232         which contains a particular bytecode offset.
2233         (JSC::computeLocalLivenessForBytecodeOffset): Computes block-local liveness from the 
2234         bottom of the block until a specified bytecode offset is reached. 
2235         (JSC::computeLocalLivenessForBlock): Computes liveness for the entire block and 
2236         stores the resulting liveness at the head.
2237         (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): Runs backward flow liveness 
2238         analysis to fixpoint.
2239         (JSC::BytecodeLivenessAnalysis::getLivenessInfoForNonCapturedVarsAtBytecodeOffset): 
2240         Slow path to get liveness info for non-captured, non-argument variable.
2241         (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): 
2242         (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset): Returns the liveness 
2243         info for both captured and non-captured vars at a particular bytecode offset.
2244         (JSC::BytecodeLivenessAnalysis::dumpResults): Dumps the output of the liveness analysis. 
2245         Controlled by new flag in Options.h/.cpp.
2246         (JSC::BytecodeLivenessAnalysis::compute): Creates bytecode basic blocks and runs 
2247         full liveness analysis.
2248         * bytecode/BytecodeLivenessAnalysis.h: Added.
2249         (JSC::BytecodeLivenessAnalysis::hasBeenComputed):
2250         (JSC::BytecodeLivenessAnalysis::computeIfNecessary):
2251         * bytecode/CodeBlock.cpp:
2252         (JSC::CodeBlock::CodeBlock):
2253         * bytecode/CodeBlock.h:
2254         (JSC::CodeBlock::livenessAnalysis):
2255         * bytecode/PreciseJumpTargets.cpp: Refactored to be able to get the jump targets for 
2256         a particular bytecode offset for use during bytecode basic block construction.
2257         (JSC::getJumpTargetsForBytecodeOffset):
2258         (JSC::computePreciseJumpTargets):
2259         (JSC::findJumpTargetsForBytecodeOffset):
2260         * bytecode/PreciseJumpTargets.h:
2261         * runtime/Options.cpp:
2262         (JSC::Options::initialize):
2263         * runtime/Options.h:
2264
2265 2013-11-11  Andy Estes  <aestes@apple.com>
2266
2267         [iOS] Define JSC_OBJC_API_ENABLED
2268         https://bugs.webkit.org/show_bug.cgi?id=124192
2269
2270         Reviewed by Geoffrey Garen.
2271
2272         * API/JSBase.h: JSC_OBJC_API_ENABLED should evaluate to true if
2273         TARGET_OS_IPHONE is true.
2274         * API/JSValue.h: Ensure CG types referenced later in the file are defined.
2275
2276 2013-11-12  Balazs Kilvady  <kilvadyb@homejinni.com>
2277
2278         Fix undefined reference issues in JavaScriptCore build.
2279         https://bugs.webkit.org/show_bug.cgi?id=124152
2280
2281         Reviewed by Michael Saboff.
2282
2283         Missing includes added.
2284
2285         * runtime/SymbolTable.cpp:
2286
2287 2013-11-12  Alexandru Chiculita  <achicu@adobe.com>
2288
2289         Web Inspector: Crash when closing the Inspector while debugging an exception inside a breakpoint condition.
2290         https://bugs.webkit.org/show_bug.cgi?id=124078
2291
2292         Reviewed by Joseph Pecoraro.
2293
2294         The crash would happen because the Debugger is not designed to support nested
2295         breaks. For example, when the debugger handles a breakpoint and the Inspector
2296         executes a console command that would hit the breakpoint again, the Debugger
2297         will just ignore the breakpoint.
2298
2299         There were no checks for conditions and actions. Because of that conditions and actions
2300         could trigger exceptions and breakpoints. This patch disables that functionality as it
2301         cannot be supported without a bigger rewrite of the code.
2302
2303         * debugger/Debugger.cpp:
2304         (JSC::TemporaryPausedState::TemporaryPausedState):
2305         (JSC::TemporaryPausedState::~TemporaryPausedState):
2306         (JSC::Debugger::hasBreakpoint):
2307         (JSC::Debugger::pauseIfNeeded):
2308         * debugger/Debugger.h:
2309
2310 2013-11-12  Julien Brianceau  <jbriance@cisco.com>
2311
2312         InvalidIndex shouldn't be private in GPRInfo and FPRInfo for sh4, mips and arm64 architectures.
2313         https://bugs.webkit.org/show_bug.cgi?id=124156
2314
2315         Reviewed by Michael Saboff.
2316
2317         * jit/FPRInfo.h:
2318         (JSC::FPRInfo::debugName):
2319         * jit/GPRInfo.h:
2320         (JSC::GPRInfo::debugName):
2321
2322 2013-11-11  Andreas Kling  <akling@apple.com>
2323
2324         CodeBlock: Un-segment some Vectors.
2325         <https://webkit.org/b/124188>
2326
2327         Turn some SegmentedVectors into Vectors where the final item count
2328         is known at CodeBlock construction time. This removes unnecessary
2329         allocation and indirection.
2330
2331         I've got ~4.5 MB below SegmentedVector<ValueProfile>::ensureSegment
2332         on Membuster3 (peak, before pressure signal) so this should help
2333         take a bit of the edge off there.
2334
2335         Reviewed by Geoffrey Garen.
2336
2337 2013-11-11  Filip Pizlo  <fpizlo@apple.com>
2338
2339         Get rid of the lastResultRegister optimization in the baseline JIT
2340         https://bugs.webkit.org/show_bug.cgi?id=124171
2341
2342         Rubber stamped by Mark Hahnenberg.
2343         
2344         The baseline JIT no longer needs amazing throughput. And this optimization has caused
2345         way too many OSR exit bugs. And it constrains how much we can do in the DFG/FTL. So,
2346         I'm getting rid of it.
2347
2348         * dfg/DFGOSRExit.cpp:
2349         (JSC::DFG::OSRExit::OSRExit):
2350         (JSC::DFG::OSRExit::convertToForward):
2351         * dfg/DFGOSRExit.h:
2352         * dfg/DFGOSRExitCompiler32_64.cpp:
2353         (JSC::DFG::OSRExitCompiler::compileExit):
2354         * dfg/DFGOSRExitCompiler64.cpp:
2355         (JSC::DFG::OSRExitCompiler::compileExit):
2356         * dfg/DFGSpeculativeJIT.cpp:
2357         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
2358         (JSC::DFG::SpeculativeJIT::compileMovHint):
2359         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2360         * dfg/DFGSpeculativeJIT.h:
2361         * ftl/FTLLowerDFGToLLVM.cpp:
2362         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
2363         (JSC::FTL::LowerDFGToLLVM::compileZombieHint):
2364         (JSC::FTL::LowerDFGToLLVM::compileInvalidationPoint):
2365         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
2366         (JSC::FTL::LowerDFGToLLVM::observeMovHint):
2367         * ftl/FTLOSRExit.cpp:
2368         (JSC::FTL::OSRExit::OSRExit):
2369         (JSC::FTL::OSRExit::convertToForward):
2370         * ftl/FTLOSRExit.h:
2371         * ftl/FTLOSRExitCompiler.cpp:
2372         (JSC::FTL::compileStub):
2373         * jit/JIT.cpp:
2374         (JSC::JIT::JIT):
2375         (JSC::JIT::privateCompileMainPass):
2376         (JSC::JIT::privateCompileSlowCases):
2377         * jit/JIT.h:
2378         (JSC::JIT::appendCall):
2379         * jit/JITArithmetic32_64.cpp:
2380         (JSC::JIT::emit_op_lshift):
2381         (JSC::JIT::emitRightShift):
2382         (JSC::JIT::emit_op_bitand):
2383         (JSC::JIT::emit_op_bitor):
2384         (JSC::JIT::emit_op_bitxor):
2385         (JSC::JIT::emit_op_inc):
2386         (JSC::JIT::emit_op_dec):
2387         * jit/JITCall.cpp:
2388         (JSC::JIT::emitPutCallResult):
2389         (JSC::JIT::compileLoadVarargs):
2390         * jit/JITInlines.h:
2391         (JSC::JIT::emitGetFromCallFrameHeaderPtr):
2392         (JSC::JIT::emitGetFromCallFrameHeader32):
2393         (JSC::JIT::emitGetFromCallFrameHeader64):
2394         (JSC::JIT::emitLoadTag):
2395         (JSC::JIT::emitLoadPayload):
2396         (JSC::JIT::emitLoad2):
2397         (JSC::JIT::emitGetVirtualRegister):
2398         (JSC::JIT::emitGetVirtualRegisters):
2399         (JSC::JIT::emitPutVirtualRegister):
2400         * jit/JITOpcodes.cpp:
2401         (JSC::JIT::emit_op_mov):
2402         (JSC::JIT::emit_op_catch):
2403         (JSC::JIT::emit_op_new_func):
2404         * jit/JITOpcodes32_64.cpp:
2405         (JSC::JIT::emit_op_mov):
2406         (JSC::JIT::emit_op_to_primitive):
2407         (JSC::JIT::emit_op_to_number):
2408         (JSC::JIT::emit_op_catch):
2409         * jit/JITPropertyAccess.cpp:
2410         (JSC::JIT::emit_op_resolve_scope):
2411         (JSC::JIT::emit_op_get_from_scope):
2412         (JSC::JIT::emit_op_put_to_scope):
2413         * jit/JITPropertyAccess32_64.cpp:
2414         (JSC::JIT::emit_op_get_by_val):
2415         (JSC::JIT::emit_op_get_by_id):
2416         (JSC::JIT::emit_op_get_by_pname):
2417         (JSC::JIT::emitResolveClosure):
2418         (JSC::JIT::emit_op_resolve_scope):
2419         (JSC::JIT::emit_op_get_from_scope):
2420         (JSC::JIT::emit_op_init_global_const):
2421         * jit/SlowPathCall.h:
2422         (JSC::JITSlowPathCall::call):
2423
2424 2013-11-11  Filip Pizlo  <fpizlo@apple.com>
2425
2426         Remove ConstantFoldingPhase's weirdo compile-time optimization
2427         https://bugs.webkit.org/show_bug.cgi?id=124169
2428
2429         Reviewed by Mark Hahnenberg.
2430         
2431         It turns out that this compile-time optimization doesn't optimize compile times
2432         anymore. Kill it with fire.
2433
2434         * dfg/DFGConstantFoldingPhase.cpp:
2435         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2436
2437 2013-11-11  Filip Pizlo  <fpizlo@apple.com>
2438
2439         Make bytecode dumping use the right opcode names for inc/dec.
2440
2441         Rubber stamped by Mark Hahnenberg.
2442
2443         * bytecode/CodeBlock.cpp:
2444         (JSC::CodeBlock::dumpBytecode):
2445
2446 2013-11-10  Filip Pizlo  <fpizlo@apple.com>
2447
2448         DFG Int52 boxing code may clobber the source without telling anyone
2449         https://bugs.webkit.org/show_bug.cgi?id=124137
2450
2451         Reviewed by Mark Hahnenberg.
2452
2453         * dfg/DFGSpeculativeJIT64.cpp:
2454         (JSC::DFG::SpeculativeJIT::boxInt52): This is called in places where source is expected to be unchanged. We never call this expecting super-amazing codegen. So, preserve the source's value the dumb way (by recovering it mathematically).
2455         * jit/AssemblyHelpers.h: Document the invariant for boxInt52.
2456         * jsc.cpp:
2457         (GlobalObject::finishCreation): It's been super annoying that sometimes we say noInline() and sometimes we say neverInlineFunction(). The LayoutTests harnesses ensure that we have something called noInline(), but it's great to also ensure that the shell has it.
2458
2459 2013-11-11  Oliver Hunt  <oliver@apple.com>
2460
2461         ExtJS breaks with modern Array.prototype.values API due to use of with()
2462         https://bugs.webkit.org/show_bug.cgi?id=123440
2463
2464         Reviewed by Beth Dakin.
2465
2466         As with our attempt to make Arguments use the Array prototype, ExtJS has
2467         a weird dependency on not adding new APIs to core types.  In this case
2468         Array.prototype.values.  The fix is to remove it, and push for ES6 to drop
2469         the API.
2470
2471         * runtime/ArrayPrototype.cpp:
2472
2473 2013-11-11  Gabor Rapcsanyi  <rgabor@webkit.org>
2474
2475         Fix CPU(ARM_TRADITIONAL) build after r159039.
2476         https://bugs.webkit.org/show_bug.cgi?id=124149
2477
2478         Reviewed by Geoffrey Garen.
2479
2480         * assembler/ARMAssembler.h:
2481         (JSC::ARMAssembler::firstRegister):
2482         (JSC::ARMAssembler::lastRegister):
2483         (JSC::ARMAssembler::firstFPRegister):
2484         (JSC::ARMAssembler::lastFPRegister):
2485         * assembler/MacroAssemblerARM.h:
2486         * jit/FPRInfo.h:
2487
2488 2013-11-09  Filip Pizlo  <fpizlo@apple.com>
2489
2490         Switch FTL GetById/PutById IC's over to using AnyRegCC
2491         https://bugs.webkit.org/show_bug.cgi?id=124094
2492
2493         Reviewed by Sam Weinig.
2494         
2495         This closes the loop on inline caches (IC's) in the FTL. The goal is to have IC's
2496         in LLVM-generated code that are just as efficient (if not more so) than what a
2497         custom JIT could do. As in zero sources of overhead. Not a single extra instruction
2498         or even register allocation pathology. We accomplish this by having two thingies in
2499         LLVM. First is the llvm.experimental.patchpoint intrinsic, which is sort of an
2500         inline machine code snippet that we can fill in with whatever we want and then
2501         modify subsequently. But you have only two choices of how to pass values to a
2502         patchpoint: (1) via the calling convention or (2) via the stackmap. Neither are good
2503         for operands to an IC (like the base pointer for a GetById, for example). (1) is bad
2504         because it results in things being pinned to certain registers a priori; a custom
2505         JIT (like the DFG) will not pin IC operands to any registers a priori but will allow
2506         the register allocator to do whatever it wants. (2) is bad because the operands may
2507         be spilled or may be represented in other crazy ways. You generally want an IC to
2508         have its operands in registers. Also, patchpoints only return values using the
2509         calling convention, which is unfortunate since it pins the return value to a
2510         register a priori. This is where the second thingy comes in: the AnyRegCC. This is
2511         a special calling convention only for use with patchpoints. It means that arguments
2512         passed "by CC" in the patchpoint can be placed in any register, and the register
2513         that gets used is reported as part of the stackmap. It also means that the return
2514         value (if there is one) can be placed in any register, and the stackmap will tell
2515         you which one it was. Thus, patchpoints combined with AnyRegCC mean that you not
2516         only get the kind of self-modifying code that you want for IC's, but you also get
2517         all of the register allocation goodness that a custom JIT would have given you.
2518         Except that you're getting it from LLVM and not a custom JIT. Awesome.
2519         
2520         Even though all of the fun stuff is on the LLVM side, this patch was harder than
2521         you'd expect.
2522         
2523         First the obvious bits:
2524         
2525         - IC patchpoints now use AnyRegCC instead of the C CC. (CC = calling convention.)
2526         
2527         - FTL::fixFunctionBasedOnStackMaps() now correctly figures out which registers the
2528           IC is supposed to use instead of assuming C CC argument registers.
2529         
2530         And then all of the stuff that broke and that this patch fixes:
2531         
2532         - IC sizing based on generating a dummy IC (what FTLInlineCacheSize did) is totally
2533           bad on x86-64, where various register permutations lead to bizarre header bytes
2534           and eclectic SIB encodings. I changed that to have magic constants, for now.
2535         
2536         - Slow path calls didn't preserve the CC return register.
2537         
2538         - Repatch's scratch register allocation would get totally confused if the operand
2539           registers weren't one of the DFG-style "temp" registers. And by "totally confused"
2540           I mean that it would crash.
2541         
2542         - We assumed that r10 is callee-saved. It's not. That one dude's PPT about x86-64
2543           cdecl that I found on the intertubes was not a trustworthy source of information,
2544           apparently.
2545         
2546         - Call repatching didn't know that the FTL does its IC slow calls via specially
2547           generated thunks. This was particularly fun to fix: basically, now when we relink
2548           an IC call in the FTL, we use the old call target to find the SlowPathCallKey,
2549           which tells us everything we need to know to generate (or look up) a new thunk for
2550           the new function we want to call.
2551         
2552         * assembler/MacroAssemblerCodeRef.h:
2553         (JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
2554         (JSC::MacroAssemblerCodePtr::isEmptyValue):
2555         (JSC::MacroAssemblerCodePtr::isDeletedValue):
2556         (JSC::MacroAssemblerCodePtr::hash):
2557         (JSC::MacroAssemblerCodePtr::emptyValue):
2558         (JSC::MacroAssemblerCodePtr::deletedValue):
2559         (JSC::MacroAssemblerCodePtrHash::hash):
2560         (JSC::MacroAssemblerCodePtrHash::equal):
2561         * assembler/MacroAssemblerX86Common.h:
2562         * assembler/RepatchBuffer.h:
2563         (JSC::RepatchBuffer::RepatchBuffer):
2564         (JSC::RepatchBuffer::codeBlock):
2565         * ftl/FTLAbbreviations.h:
2566         (JSC::FTL::setInstructionCallingConvention):
2567         * ftl/FTLCompile.cpp:
2568         (JSC::FTL::fixFunctionBasedOnStackMaps):
2569         * ftl/FTLInlineCacheSize.cpp:
2570         (JSC::FTL::sizeOfGetById):
2571         (JSC::FTL::sizeOfPutById):
2572         * ftl/FTLJITFinalizer.cpp:
2573         (JSC::FTL::JITFinalizer::finalizeFunction):
2574         * ftl/FTLLocation.cpp:
2575         (JSC::FTL::Location::forStackmaps):
2576         * ftl/FTLLocation.h:
2577         * ftl/FTLLowerDFGToLLVM.cpp:
2578         (JSC::FTL::LowerDFGToLLVM::compileGetById):
2579         (JSC::FTL::LowerDFGToLLVM::compilePutById):
2580         * ftl/FTLOSRExitCompiler.cpp:
2581         (JSC::FTL::compileStub):
2582         * ftl/FTLSlowPathCall.cpp:
2583         * ftl/FTLSlowPathCallKey.h:
2584         (JSC::FTL::SlowPathCallKey::withCallTarget):
2585         * ftl/FTLStackMaps.cpp:
2586         (JSC::FTL::StackMaps::Location::directGPR):
2587         (JSC::FTL::StackMaps::Location::restoreInto):
2588         * ftl/FTLStackMaps.h:
2589         * ftl/FTLThunks.h:
2590         (JSC::FTL::generateIfNecessary):
2591         (JSC::FTL::keyForThunk):
2592         (JSC::FTL::Thunks::keyForSlowPathCallThunk):
2593         * jit/FPRInfo.h:
2594         (JSC::FPRInfo::toIndex):
2595         * jit/GPRInfo.h:
2596         (JSC::GPRInfo::toIndex):
2597         (JSC::GPRInfo::debugName):
2598         * jit/RegisterSet.cpp:
2599         (JSC::RegisterSet::calleeSaveRegisters):
2600         * jit/RegisterSet.h:
2601         (JSC::RegisterSet::filter):
2602         * jit/Repatch.cpp:
2603         (JSC::readCallTarget):
2604         (JSC::repatchCall):
2605         (JSC::repatchByIdSelfAccess):
2606         (JSC::tryCacheGetByID):
2607         (JSC::tryCachePutByID):
2608         (JSC::tryBuildPutByIdList):
2609         (JSC::resetGetByID):
2610         (JSC::resetPutByID):
2611         * jit/ScratchRegisterAllocator.h:
2612         (JSC::ScratchRegisterAllocator::lock):
2613
2614 2013-11-10  Oliver Hunt  <oliver@apple.com>
2615
2616         Implement Set iterators
2617         https://bugs.webkit.org/show_bug.cgi?id=124129
2618
2619         Reviewed by Antti Koivisto.
2620
2621         Add Set iterator classes and implementations
2622
2623         * JavaScriptCore.xcodeproj/project.pbxproj:
2624         * runtime/CommonIdentifiers.h:
2625         * runtime/JSGlobalObject.cpp:
2626         * runtime/JSGlobalObject.h:
2627         * runtime/JSSetIterator.cpp: Added.
2628         (JSC::JSSetIterator::finishCreation):
2629         (JSC::JSSetIterator::visitChildren):
2630         (JSC::JSSetIterator::createPair):
2631         * runtime/JSSetIterator.h: Added.
2632         (JSC::JSSetIterator::createStructure):
2633         (JSC::JSSetIterator::create):
2634         (JSC::JSSetIterator::next):
2635         (JSC::JSSetIterator::JSSetIterator):
2636         * runtime/SetIteratorConstructor.cpp: Added.
2637         (JSC::SetIteratorConstructor::finishCreation):
2638         * runtime/SetIteratorConstructor.h: Added.
2639         (JSC::SetIteratorConstructor::create):
2640         (JSC::SetIteratorConstructor::createStructure):
2641         (JSC::SetIteratorConstructor::SetIteratorConstructor):
2642         * runtime/SetIteratorPrototype.cpp: Added.
2643         (JSC::SetIteratorPrototype::finishCreation):
2644         (JSC::SetIteratorPrototypeFuncIterator):
2645         (JSC::SetIteratorPrototypeFuncNext):
2646         * runtime/SetIteratorPrototype.h: Added.
2647         (JSC::SetIteratorPrototype::create):
2648         (JSC::SetIteratorPrototype::createStructure):
2649         (JSC::SetIteratorPrototype::SetIteratorPrototype):
2650         * runtime/SetPrototype.cpp:
2651         (JSC::SetPrototype::finishCreation):
2652         (JSC::setProtoFuncValues):
2653         (JSC::setProtoFuncEntries):
2654         (JSC::setProtoFuncKeys):
2655
2656 2013-11-09  Oliver Hunt  <oliver@apple.com>
2657
2658         Add Map Iterators
2659         https://bugs.webkit.org/show_bug.cgi?id=124109
2660
2661         Reviewed by Andreas Kling.
2662
2663         Added new Map iterator implementation.  This is a mostly boilerplate patch
2664         however there's a a little bit of additional logic added to the MapData iterator
2665         to deal with the possibility of map mutation between creation of the iterator
2666         and use of it.  We'll be able to improve the performance of this substantially
2667         by using intrinsics, however I'm pondering coming up with a better way to define
2668         these thunks without requiring so much duplicated logic.
2669
2670         * CMakeLists.txt:
2671         * GNUmakefile.list.am:
2672         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2673         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2674         * JavaScriptCore.xcodeproj/project.pbxproj:
2675         * runtime/CommonIdentifiers.h:
2676         * runtime/JSGlobalObject.cpp:
2677         * runtime/JSGlobalObject.h:
2678         * runtime/JSMapIterator.cpp: Added.
2679         (JSC::JSMapIterator::finishCreation):
2680         (JSC::JSMapIterator::visitChildren):
2681         (JSC::JSMapIterator::createPair):
2682         * runtime/JSMapIterator.h: Added.
2683         (JSC::JSMapIterator::createStructure):
2684         (JSC::JSMapIterator::create):
2685         (JSC::JSMapIterator::next):
2686         (JSC::JSMapIterator::JSMapIterator):
2687         * runtime/MapData.h:
2688         (JSC::MapData::const_iterator::ensureSlot):
2689         * runtime/MapIteratorConstructor.cpp: Added.
2690         (JSC::MapIteratorConstructor::finishCreation):
2691         * runtime/MapIteratorConstructor.h: Added.
2692         (JSC::MapIteratorConstructor::create):
2693         (JSC::MapIteratorConstructor::createStructure):
2694         (JSC::MapIteratorConstructor::MapIteratorConstructor):
2695         * runtime/MapIteratorPrototype.cpp: Added.
2696         (JSC::MapIteratorPrototype::finishCreation):
2697         (JSC::MapIteratorPrototypeFuncIterator):
2698         (JSC::MapIteratorPrototypeFuncNext):
2699         * runtime/MapIteratorPrototype.h: Added.
2700         (JSC::MapIteratorPrototype::create):
2701         (JSC::MapIteratorPrototype::createStructure):
2702         (JSC::MapIteratorPrototype::MapIteratorPrototype):
2703         * runtime/MapPrototype.cpp:
2704         (JSC::MapPrototype::finishCreation):
2705         (JSC::mapProtoFuncValues):
2706         (JSC::mapProtoFuncEntries):
2707         (JSC::mapProtoFuncKeys):
2708
2709 2013-11-08  Zan Dobersek  <zdobersek@igalia.com>
2710
2711         Unreviewed GTK build fix.
2712
2713         * GNUmakefile.list.am: Remove redundant build targets.
2714
2715 2013-11-08  Filip Pizlo  <fpizlo@apple.com>
2716
2717         Remove dead FTL C ABI support
2718         https://bugs.webkit.org/show_bug.cgi?id=124100
2719
2720         Reviewed by Jer Noble.
2721
2722         * JavaScriptCore.xcodeproj/project.pbxproj:
2723         * ftl/FTLCArgumentGetter.cpp: Removed.
2724         * ftl/FTLCArgumentGetter.h: Removed.
2725         * ftl/FTLOSRExitCompiler.cpp:
2726         * jit/FPRInfo.h:
2727
2728 2013-11-08  Filip Pizlo  <fpizlo@apple.com>
2729
2730         FTL should support Phantom(FinalObject:)
2731         https://bugs.webkit.org/show_bug.cgi?id=124092
2732
2733         Reviewed by Oliver Hunt.
2734
2735         * ftl/FTLAbstractHeapRepository.h:
2736         * ftl/FTLCapabilities.cpp:
2737         (JSC::FTL::canCompile):
2738         * ftl/FTLLowerDFGToLLVM.cpp:
2739         (JSC::FTL::LowerDFGToLLVM::speculate):
2740         (JSC::FTL::LowerDFGToLLVM::isType):
2741         (JSC::FTL::LowerDFGToLLVM::isNotType):
2742         (JSC::FTL::LowerDFGToLLVM::speculateFinalObject):
2743
2744 2013-11-08  Filip Pizlo  <fpizlo@apple.com>
2745
2746         Get rid of the FTL tail call APIs since they are unused
2747         https://bugs.webkit.org/show_bug.cgi?id=124093
2748
2749         Reviewed by Oliver Hunt.
2750
2751         * ftl/FTLAbbreviations.h:
2752         (JSC::FTL::buildCall):
2753         * ftl/FTLOutput.h:
2754
2755 2013-11-08  Filip Pizlo  <fpizlo@apple.com>
2756
2757         FTL should support AllocatePropertyStorage
2758         https://bugs.webkit.org/show_bug.cgi?id=124086
2759
2760         Reviewed by Oliver Hunt.
2761         
2762         Also rationalized some offsets in the DFG.
2763
2764         * dfg/DFGSpeculativeJIT.cpp:
2765         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
2766         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
2767         * ftl/FTLCapabilities.cpp:
2768         (JSC::FTL::canCompile):
2769         * ftl/FTLIntrinsicRepository.h:
2770         * ftl/FTLLowerDFGToLLVM.cpp:
2771         (JSC::FTL::LowerDFGToLLVM::compileNode):
2772         (JSC::FTL::LowerDFGToLLVM::compileAllocatePropertyStorage):
2773
2774 2013-11-08  Filip Pizlo  <fpizlo@apple.com>
2775
2776         Get rid of the bizarre Darwin/x86-only MacroAssembler::shouldBlindForSpecificArch(uintptr_t) overload
2777         https://bugs.webkit.org/show_bug.cgi?id=124087
2778
2779         Reviewed by Michael Saboff.
2780
2781         * assembler/MacroAssembler.h:
2782         (JSC::MacroAssembler::shouldBlindPointerForSpecificArch):
2783         (JSC::MacroAssembler::shouldBlind):
2784         * assembler/MacroAssemblerX86Common.h:
2785         (JSC::MacroAssemblerX86Common::shouldBlindForSpecificArch):
2786
2787 2013-11-08  Filip Pizlo  <fpizlo@apple.com>
2788
2789         FTL should support NewArrayBuffer
2790         https://bugs.webkit.org/show_bug.cgi?id=124067
2791
2792         Reviewed by Michael Saboff.
2793         
2794         This expanded coverage and revealed some bugs.
2795         
2796         This revealed a bug in FTL::OSRExitCompiler where it was assuming that it could save
2797         the framePointer in regT3 even though DFG::reifyInlinedCallFrames() would clobber it.
2798         It turns out that this can be fixed by just completely restoring the stack prior to
2799         doing reifyInlineCallFrames().
2800         
2801         I used this as an opportunity to simplify NewArray. That revealed a bug; whenever we say
2802         lowJSValue() in there we need to use ManualOperandSpeculation since we're using it to
2803         rebox values even when we also have to do some speculations. The speculations are done
2804         at the top of compileNewArray().
2805         
2806         This also revealed a bug in StringCharAt() for the OOB case.
2807
2808         * ftl/FTLAbstractHeapRepository.h:
2809         (JSC::FTL::AbstractHeapRepository::forIndexingType):
2810         * ftl/FTLCapabilities.cpp:
2811         (JSC::FTL::canCompile):
2812         * ftl/FTLIntrinsicRepository.h:
2813         * ftl/FTLLowerDFGToLLVM.cpp:
2814         (JSC::FTL::LowerDFGToLLVM::compileNode):
2815         (JSC::FTL::LowerDFGToLLVM::compileNewArray):
2816         (JSC::FTL::LowerDFGToLLVM::compileNewArrayBuffer):
2817         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
2818         * ftl/FTLOSRExitCompiler.cpp:
2819         (JSC::FTL::compileStub):
2820
2821 2013-11-08  Filip Pizlo  <fpizlo@apple.com>
2822
2823         It should be easy to disable blinding on a per-architecture basis
2824         https://bugs.webkit.org/show_bug.cgi?id=124083
2825
2826         Reviewed by Michael Saboff.
2827
2828         * assembler/AbstractMacroAssembler.h:
2829         (JSC::AbstractMacroAssembler::haveScratchRegisterForBlinding):
2830         (JSC::AbstractMacroAssembler::scratchRegisterForBlinding):
2831         (JSC::AbstractMacroAssembler::canBlind):
2832         (JSC::AbstractMacroAssembler::shouldBlindForSpecificArch):
2833         * assembler/MacroAssembler.h:
2834         (JSC::MacroAssembler::shouldBlind):
2835         (JSC::MacroAssembler::store32):
2836         (JSC::MacroAssembler::branch32):
2837         (JSC::MacroAssembler::branchAdd32):
2838         (JSC::MacroAssembler::branchMul32):
2839         * assembler/MacroAssemblerX86Common.h:
2840         (JSC::MacroAssemblerX86Common::canBlind):
2841         * assembler/MacroAssemblerX86_64.h:
2842         (JSC::MacroAssemblerX86_64::haveScratchRegisterForBlinding):
2843
2844 2013-11-08  Oliver Hunt  <oliver@apple.com>
2845
2846         Remove more accidentally added files.
2847
2848         * runtime/SetIteratorConstructor.cpp: Removed.
2849         * runtime/SetIteratorConstructor.h: Removed.
2850         * runtime/SetIteratorPrototype.cpp: Removed.
2851         * runtime/SetIteratorPrototype.h: Removed.
2852
2853 2013-11-08  Oliver Hunt  <oliver@apple.com>
2854
2855         Remove accidentally added files.
2856
2857         * runtime/JSSetIterator.cpp: Removed.
2858         * runtime/JSSetIterator.h: Removed.
2859
2860 2013-11-08  Oliver Hunt  <oliver@apple.com>
2861
2862         Fix minor (unobservable) bug in ArrayIterator::next()
2863         https://bugs.webkit.org/show_bug.cgi?id=124061
2864
2865         Reviewed by Beth Dakin.
2866
2867         I noticed this while reading the array iterator code.  Due to how
2868         ArrayIterator::next() and our enumeration behaviour is implemented
2869         this is not actually a code path that can be hit.  But in order to
2870         future proof this it should be correct.
2871         
2872         * runtime/JSArrayIterator.cpp:
2873         (JSC::arrayIteratorNext):
2874
2875 2013-11-08  Mark Lam  <mark.lam@apple.com>
2876
2877         Move breakpoint (and exception break) functionality into JSC::Debugger.
2878         https://bugs.webkit.org/show_bug.cgi?id=121796.
2879
2880         Reviewed by Geoffrey Garen.
2881
2882         - In ScriptDebugServer and JSC::Debugger, SourceID and BreakpointID are
2883           now numeric tokens.
2884
2885         - JSC::Debugger now tracks user defined breakpoints in a JSC::Breakpoint
2886           record. Previously, this info is tracked in the ScriptBreakpoint record
2887           in ScriptDebugServer. The only element of ScriptBreakpoint that is not
2888           being tracked by JSC::Breakpoint is the ScriptBreakpointAction.
2889              The ScriptBreakpointAction is still tracked by the ScriptDebugServer
2890           in a list keyed on the corresponding BreakpointID.
2891              The ScriptBreakpoint record is now only used as a means of passing
2892           breakpoint paramaters to the ScriptDebugServer.
2893
2894         - ScriptDebugServer now no longer accesses the JSC::CallFrame* directly.
2895           It always goes through the DebuggerCallFrame.
2896
2897         * GNUmakefile.list.am:
2898         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2899         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2900         * JavaScriptCore.xcodeproj/project.pbxproj:
2901         * debugger/Breakpoint.h: Added.
2902         (JSC::Breakpoint::Breakpoint):
2903         - Breakpoint class to track info for each breakpoint in JSC::Debugger.
2904         * debugger/Debugger.cpp:
2905         (JSC::DebuggerCallFrameScope::DebuggerCallFrameScope):
2906         (JSC::DebuggerCallFrameScope::~DebuggerCallFrameScope):
2907         (JSC::Debugger::Debugger):
2908         (JSC::Debugger::detach):
2909         (JSC::Debugger::updateNeedForOpDebugCallbacks):
2910         (JSC::Debugger::setBreakpoint):
2911         (JSC::Debugger::removeBreakpoint):
2912         (JSC::Debugger::hasBreakpoint):
2913         (JSC::Debugger::clearBreakpoints):
2914         (JSC::Debugger::setBreakpointsActivated):
2915         (JSC::Debugger::setPauseOnExceptionsState):
2916         (JSC::Debugger::setPauseOnNextStatement):
2917         (JSC::Debugger::breakProgram):
2918         (JSC::Debugger::continueProgram):
2919         (JSC::Debugger::stepIntoStatement):
2920         (JSC::Debugger::stepOverStatement):
2921         (JSC::Debugger::stepOutOfFunction):
2922         (JSC::Debugger::updateCallFrame):
2923         (JSC::Debugger::updateCallFrameAndPauseIfNeeded):
2924         (JSC::Debugger::pauseIfNeeded):
2925         (JSC::Debugger::exception):
2926         (JSC::Debugger::atStatement):
2927         (JSC::Debugger::callEvent):
2928         (JSC::Debugger::returnEvent):
2929         (JSC::Debugger::willExecuteProgram):
2930         (JSC::Debugger::didExecuteProgram):
2931         (JSC::Debugger::didReachBreakpoint):
2932         (JSC::Debugger::currentDebuggerCallFrame):
2933         * debugger/Debugger.h:
2934         * debugger/DebuggerCallFrame.cpp:
2935         (JSC::DebuggerCallFrame::sourceID):
2936         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
2937         * debugger/DebuggerCallFrame.h:
2938         * debugger/DebuggerPrimitives.h: Added.
2939         - define SourceID, noSourceID, BreakpointID, and noBreakpointID.
2940
2941 2013-11-08  Oliver Hunt  <oliver@apple.com>
2942
2943         Map.forEach crashes on deleted values
2944         https://bugs.webkit.org/show_bug.cgi?id=124017
2945
2946         Reviewed by Ryosuke Niwa.
2947
2948         MapData iterator did not consider the case of the first entries
2949         being holes.  To fix this I've refactored iteration so that we
2950         can perform an initialisation increment on construction, whle
2951         retaining the useful assertion in MapData::const_iterator::operator++
2952
2953         * runtime/MapData.h:
2954         (JSC::MapData::const_iterator::operator++):
2955         (JSC::MapData::const_iterator::internalIncrement):
2956         (JSC::MapData::const_iterator::const_iterator):
2957
2958 2013-11-08  Julien Brianceau  <jbriance@cisco.com>
2959
2960         REGRESSION(r158883): Fix crashes for ARM architecture.
2961         https://bugs.webkit.org/show_bug.cgi?id=124038
2962
2963         Reviewed by Michael Saboff.
2964
2965         * jit/GPRInfo.h: Remove r11 from the temporary register set, use a free register for
2966         nonPreservedNonReturnGPR and remove obsolete declaration of bucketCounterRegister.
2967         (JSC::GPRInfo::toRegister):
2968         (JSC::GPRInfo::toIndex):
2969         * jit/JITOperations.cpp: Frame pointer register is r11 for ARM_TRADITIONAL and
2970         r7 for ARM_THUMB2 instead of r5 since r158883.
2971
2972 2013-11-08  Julien Brianceau  <jbriance@cisco.com>
2973
2974         REGRESSION(r158883): Fix crashes for MIPS architecture.
2975         https://bugs.webkit.org/show_bug.cgi?id=124044
2976
2977         Reviewed by Michael Saboff.
2978
2979         * jit/JITOperations.cpp: Frame pointer register is fp instead of s0 since r158883 for MIPS.
2980         * jit/ThunkGenerators.cpp: Save and restore the new frame pointer register.
2981         (JSC::returnFromJavaScript):
2982         (JSC::callToJavaScript):
2983
2984 2013-11-08  peavo@outlook.com  <peavo@outlook.com>
2985
2986         [Win] JavaScript crash in getHostCallReturnValue.
2987         https://bugs.webkit.org/show_bug.cgi?id=124040
2988
2989         Reviewed by Geoffrey Garen.
2990
2991         * jit/JITOperations.cpp: Update MSVC assembler code in getHostCallReturnValue according to gcc x86 version.
2992
2993 2013-11-08  Julien Brianceau  <jbriance@cisco.com>
2994
2995         [mips] Fix typo (introduced in r158751).
2996         https://bugs.webkit.org/show_bug.cgi?id=124033.
2997
2998         Reviewed by Csaba Osztrogonác.
2999
3000         * jit/ThunkGenerators.cpp:
3001         (JSC::callToJavaScript):
3002
3003 2013-11-08  Julien Brianceau  <jbriance@cisco.com>
3004
3005         [arm] Use specific PatchableJump implementation for CPU(ARM_TRADITIONAL).
3006         https://bugs.webkit.org/show_bug.cgi?id=123891
3007
3008         Reviewed by Michael Saboff.
3009
3010         Although patchableBranch32 is implemented in MacroAssemblerARM.h, the used implementation
3011         is the generic one in MacroAssembler.h. This patch fixes it and also implements the
3012         patchableJump() function for CPU(ARM_TRADITIONAL). These specific implementations are
3013         needed for this architecture backend to ensure that these jumps can be relinked.
3014
3015         * assembler/MacroAssembler.h:
3016         * assembler/MacroAssemblerARM.h:
3017         (JSC::MacroAssemblerARM::patchableJump):
3018         * jit/GPRInfo.h: Remove static_cast that are generating warnings in debug builds.
3019         (JSC::GPRInfo::toIndex):
3020         (JSC::GPRInfo::debugName):
3021
3022 2013-11-07  Mark Lam  <mark.lam@apple.com>
3023
3024         Get rid of the regT* definitions in JSInterfaceJIT.h.
3025         https://bugs.webkit.org/show_bug.cgi?id=123806.
3026
3027         Reviewed by Geoffrey Garen.
3028
3029         JSInterfaceJIT now inherits from GPRInfo and FPRInfo, and relies on them
3030         to provide all the register definitions.
3031
3032         * jit/GPRInfo.h:
3033         (JSC::GPRInfo::toArgumentRegister):
3034         * jit/JIT.cpp:
3035         (JSC::JIT::emitEnterOptimizationCheck):
3036         (JSC::JIT::privateCompile):
3037         * jit/JITArithmetic.cpp:
3038         (JSC::JIT::emit_compareAndJumpSlow):
3039         * jit/JITArithmetic32_64.cpp:
3040         (JSC::JIT::emit_compareAndJumpSlow):
3041         * jit/JITCall.cpp:
3042         (JSC::JIT::compileLoadVarargs):
3043         * jit/JITCall32_64.cpp:
3044         (JSC::JIT::compileLoadVarargs):
3045         * jit/JITInlines.h:
3046         (JSC::JIT::appendCallWithExceptionCheckSetJSValueResult):
3047         (JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
3048         * jit/JITOpcodes.cpp:
3049         (JSC::JIT::emit_op_end):
3050         (JSC::JIT::emitSlow_op_new_object):
3051         (JSC::JIT::emit_op_ret):
3052         (JSC::JIT::emit_op_ret_object_or_this):
3053         (JSC::JIT::emit_op_throw):
3054         (JSC::JIT::emit_op_get_pnames):
3055         (JSC::JIT::emit_op_switch_imm):
3056         (JSC::JIT::emit_op_switch_char):
3057         (JSC::JIT::emit_op_switch_string):
3058         (JSC::JIT::emit_op_create_activation):
3059         (JSC::JIT::emit_op_create_arguments):
3060         (JSC::JIT::emitSlow_op_jfalse):
3061         (JSC::JIT::emitSlow_op_jtrue):
3062         (JSC::JIT::emitSlow_op_eq):
3063         (JSC::JIT::emitSlow_op_neq):
3064         (JSC::JIT::emitSlow_op_get_argument_by_val):
3065         (JSC::JIT::emitSlow_op_loop_hint):
3066         * jit/JITOpcodes32_64.cpp:
3067         (JSC::JIT::privateCompileCTINativeCall):
3068         (JSC::JIT::emit_op_end):
3069         (JSC::JIT::emitSlow_op_new_object):
3070         (JSC::JIT::emitSlow_op_jfalse):
3071         (JSC::JIT::emitSlow_op_jtrue):
3072         (JSC::JIT::emitSlow_op_eq):
3073         (JSC::JIT::emitSlow_op_neq):
3074         (JSC::JIT::emit_op_throw):
3075         (JSC::JIT::emit_op_get_pnames):
3076         (JSC::JIT::emit_op_switch_imm):
3077         (JSC::JIT::emit_op_switch_char):
3078         (JSC::JIT::emit_op_switch_string):
3079         (JSC::JIT::emit_op_create_activation):
3080         (JSC::JIT::emit_op_create_arguments):
3081         (JSC::JIT::emitSlow_op_get_argument_by_val):
3082         * jit/JSInterfaceJIT.h:
3083         (JSC::JSInterfaceJIT::JSInterfaceJIT):
3084         * jit/SlowPathCall.h:
3085         (JSC::JITSlowPathCall::call):
3086         * jit/ThunkGenerators.cpp:
3087
3088 2013-11-07  Filip Pizlo  <fpizlo@apple.com>
3089
3090         FTL should support NewArray
3091         https://bugs.webkit.org/show_bug.cgi?id=124010
3092
3093         Reviewed by Oliver Hunt.
3094
3095         * ftl/FTLCapabilities.cpp:
3096         (JSC::FTL::canCompile):
3097         * ftl/FTLIntrinsicRepository.h:
3098         * ftl/FTLLowerDFGToLLVM.cpp:
3099         (JSC::FTL::LowerDFGToLLVM::compileNode):
3100         (JSC::FTL::LowerDFGToLLVM::compileNewObject):
3101         (JSC::FTL::LowerDFGToLLVM::compileNewArray):
3102         (JSC::FTL::LowerDFGToLLVM::allocateCell):
3103         (JSC::FTL::LowerDFGToLLVM::allocateObject):
3104         (JSC::FTL::LowerDFGToLLVM::allocateBasicStorageAndGetEnd):
3105         (JSC::FTL::LowerDFGToLLVM::ArrayValues::ArrayValues):
3106         (JSC::FTL::LowerDFGToLLVM::allocateJSArray):
3107         * ftl/FTLOutput.h:
3108         (JSC::FTL::Output::loadDouble):
3109         (JSC::FTL::Output::storeDouble):
3110
3111 2013-11-07  Michael Saboff  <msaboff@apple.com>
3112
3113         Change CallFrameRegister to architected frame pointer register
3114         https://bugs.webkit.org/show_bug.cgi?id=123956
3115
3116         Reviewed by Geoffrey Garen.
3117
3118         Changed X86 and ARM variants as well as MIPS to use their respective architected
3119         frame pointer registers.  The freed up callFrameRegisteris are made available to 
3120         the DFG register allocator.  Modified the FTL OSR exit compiler to use a temporary
3121         register as a stand in for the destination callFrameRegister since the FTL frame
3122         pointer register is needed to extract values from the FTL stack.
3123
3124         Reviewed by Geoffrey Garen.
3125
3126         * assembler/ARMAssembler.h:
3127         * assembler/ARMv7Assembler.h:
3128         * assembler/MacroAssemblerMIPS.h:
3129         * ftl/FTLOSRExitCompiler.cpp:
3130         (JSC::FTL::compileStub):
3131         * jit/AssemblyHelpers.h:
3132         (JSC::AssemblyHelpers::addressFor):
3133         * jit/GPRInfo.h:
3134         (JSC::GPRInfo::toRegister):
3135         (JSC::GPRInfo::toIndex):
3136         * jit/JITOperations.cpp:
3137         * jit/JSInterfaceJIT.h:
3138         * jit/ThunkGenerators.cpp:
3139         (JSC::callToJavaScript):
3140         * offlineasm/arm.rb:
3141         * offlineasm/arm64.rb:
3142         * offlineasm/mips.rb:
3143         * offlineasm/x86.rb:
3144
3145 2013-11-07  Oliver Hunt  <oliver@apple.com>
3146
3147         Reproducible crash when using Map (affects Web Inspector)
3148         https://bugs.webkit.org/show_bug.cgi?id=123940
3149
3150         Reviewed by Geoffrey Garen.
3151
3152         Trivial fix.  Once again we get bitten by attempting to be clever when
3153         growing while adding entries to indexing maps.
3154
3155         Now we simply do a find(), and then add() _after_ we've ensured there is
3156         sufficient space in the MapData list.
3157
3158         * runtime/MapData.cpp:
3159         (JSC::MapData::add):
3160
3161 2013-11-07  Mark Lam  <mark.lam@apple.com>
3162
3163         Cosmetic: rename xxxId to xxxID for ScriptId, SourceId, and BreakpointId.
3164         https://bugs.webkit.org/show_bug.cgi?id=123945.
3165
3166         Reviewed by Geoffrey Garen.
3167
3168         * debugger/DebuggerCallFrame.cpp:
3169         (JSC::DebuggerCallFrame::sourceID):
3170         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
3171         * debugger/DebuggerCallFrame.h:
3172
3173 2013-11-07  Michael Saboff  <msaboff@apple.com>
3174
3175         returnFromJavaScript() for ARM_THUMB2 uses push()s which should be pop()s
3176         https://bugs.webkit.org/show_bug.cgi?id=124006
3177
3178         Rubber stamped by Mark Hahnenberg.
3179
3180         Changed the push() calls to pop().
3181
3182         * jit/ThunkGenerators.cpp:
3183         (JSC::returnFromJavaScript):
3184
3185 2013-11-07  Michael Saboff  <msaboff@apple.com>
3186
3187         Remove unneeded moving of ESP to ECX in callToJavaScript for COMPILER(MSVC)
3188         https://bugs.webkit.org/show_bug.cgi?id=123998
3189
3190         Reviewed by Mark Lam.
3191
3192         Dead code removal.  Passing esp as the first "C" argument to a JavaScript
3193         function is no longer needed.
3194
3195         * jit/ThunkGenerators.cpp:
3196         (JSC::callToJavaScript):
3197
3198 2013-11-07  Julien Brianceau  <jbriance@cisco.com>
3199
3200         Fix build for architectures with 4 argument registers (broken since r158820).
3201         https://bugs.webkit.org/show_bug.cgi?id=123969
3202
3203         Reviewed by Andreas Kling.
3204
3205         * jit/CCallHelpers.h:
3206         (JSC::CCallHelpers::setupArguments):
3207
3208 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3209
3210         FTL should support CheckFunction
3211         https://bugs.webkit.org/show_bug.cgi?id=123862
3212
3213         Reviewed by Sam Weinig.
3214
3215         * ftl/FTLCapabilities.cpp:
3216         (JSC::FTL::canCompile):
3217         * ftl/FTLLowerDFGToLLVM.cpp:
3218         (JSC::FTL::LowerDFGToLLVM::compileNode):
3219         (JSC::FTL::LowerDFGToLLVM::compileCheckFunction):
3220
3221 2013-11-06  Filip Pizlo  <fpizlo@apple.com>
3222
3223         IC code should handle the call frame register not being the callFrameRegister
3224         https://bugs.webkit.org/show_bug.cgi?id=123865
3225
3226         Reviewed by Geoffrey Garen.
3227         
3228         For now, in the FTL, the call frame may be something other than our frame pointer,
3229         since it's an argument passed in according to whatever convention LLVM picks.
3230         
3231         This is temporary in two ways - pretty soon the callFrameRegister will be the actual
3232         frame pointer and not some other register, and LLVM will not pass the frame pointer
3233         as an argument to IC's.
3234
3235         * bytecode/StructureStubInfo.h:
3236         * dfg/DFGSpeculativeJIT32_64.cpp:
3237         (JSC::DFG::SpeculativeJIT::cachedGetById):
3238         (JSC::DFG::SpeculativeJIT::cachedPutById):
3239         * dfg/DFGSpeculativeJIT64.cpp:
3240         (JSC::DFG::SpeculativeJIT::cachedGetById):
3241         (JSC::DFG::SpeculativeJIT::cachedPutById):
3242         * ftl/FTLCompile.cpp:
3243         (JSC::FTL::fixFunctionBasedOnStackMaps):
3244         * ftl/FTLInlineCacheSize.cpp:
3245         (JSC::FTL::sizeOfGetById):
3246         (JSC::FTL::sizeOfPutById):
3247         * jit/CCallHelpers.h:
3248         (JSC::CCallHelpers::setupArguments):
3249         * jit/JITInlineCacheGenerator.cpp:
3250         (JSC::JITByIdGenerator::JITByIdGenerator):
3251         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
3252         * jit/JITInlineCacheGenerator.h:
3253         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
3254         * jit/JITPropertyAccess.cpp:
3255         (JSC::JIT::emit_op_get_by_id):
3256         (JSC::JIT::emit_op_put_by_id):
3257         * jit/JITPropertyAccess32_64.cpp:
3258         (JSC::JIT::emit_op_get_by_id):
3259         (JSC::JIT::emit_op_put_by_id):
3260         * jit/Repatch.cpp:
3261         (JSC::tryBuildGetByIDList):
3262         (JSC::emitPutTransitionStub):
3263
3264 2013-11-06  Daniel Bates  <dabates@apple.com>
3265
3266         [iOS] Upstream Letterpress effect
3267         https://bugs.webkit.org/show_bug.cgi?id=123932
3268
3269         Reviewed by Sam Weinig.
3270
3271         Add feature define ENABLE_LETTERPRESS disabled by default. We only enable
3272         letterpress on iOS.
3273
3274         * Configurations/FeatureDefines.xcconfig:
3275
3276 2013-11-05  Oliver Hunt  <oliver@apple.com>
3277
3278         Support iteration of the Arguments object
3279         https://bugs.webkit.org/show_bug.cgi?id=123835
3280
3281         Reviewed by Mark Lam.
3282
3283         Add an ArgumentsIterator object, and associated classes so that we can support
3284         iteration of the arguments object.
3285
3286         This is a largely mechanical patch.  The only gnarliness is in the
3287         logic to avoid reifying the Arguments object in for(... of arguments)
3288         scenarios.
3289
3290         * GNUmakefile.list.am:
3291         * JavaScriptCore.xcodeproj/project.pbxproj:
3292         * bytecompiler/BytecodeGenerator.cpp:
3293         (JSC::BytecodeGenerator::emitEnumeration):
3294         * runtime/Arguments.cpp:
3295         (JSC::Arguments::getOwnPropertySlot):
3296         (JSC::argumentsFuncIterator):
3297         * runtime/Arguments.h:
3298         * runtime/ArgumentsIteratorConstructor.cpp: Added.
3299         (JSC::ArgumentsIteratorConstructor::finishCreation):
3300         * runtime/ArgumentsIteratorConstructor.h: Added.
3301         (JSC::ArgumentsIteratorConstructor::create):
3302         (JSC::ArgumentsIteratorConstructor::createStructure):
3303         (JSC::ArgumentsIteratorConstructor::ArgumentsIteratorConstructor):
3304         * runtime/ArgumentsIteratorPrototype.cpp: Added.
3305         (JSC::ArgumentsIteratorPrototype::finishCreation):
3306         (JSC::argumentsIteratorPrototypeFuncIterator):
3307         (JSC::argumentsIteratorPrototypeFuncNext):
3308         * runtime/ArgumentsIteratorPrototype.h: Added.
3309         (JSC::ArgumentsIteratorPrototype::create):
3310         (JSC::ArgumentsIteratorPrototype::createStructure):
3311         (JSC::ArgumentsIteratorPrototype::ArgumentsIteratorPrototype):
3312         * runtime/CommonIdentifiers.h:
3313         * runtime/JSArgumentsIterator.cpp: Added.
3314         (JSC::JSArgumentsIterator::finishCreation):
3315         * runtime/JSArgumentsIterator.h: Added.
3316         (JSC::JSArgumentsIterator::createStructure):
3317         (JSC::JSArgumentsIterator::create):
3318         (JSC::JSArgumentsIterator::next):
3319         (JSC::JSArgumentsIterator::JSArgumentsIterator):
3320         * runtime/JSArrayIterator.cpp:
3321         (JSC::createIteratorResult):
3322         * runtime/JSGlobalObject.cpp:
3323         * runtime/JSGlobalObject.h:
3324
3325 2013-11-06  Filip Pizlo  <fpizlo@apple.com>
3326
3327         DFG CheckArray(NonArray) should prove that the child isn't an array
3328         https://bugs.webkit.org/show_bug.cgi?id=123911
3329         <rdar://problem/15202803>
3330
3331         Reviewed by Mark Hahnenberg.
3332
3333         * dfg/DFGSpeculativeJIT.cpp:
3334         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
3335         * ftl/FTLLowerDFGToLLVM.cpp:
3336         (JSC::FTL::LowerDFGToLLVM::isArrayType):
3337
3338 2013-11-06  Mark Hahnenberg  <mhahnenberg@apple.com>
3339
3340         JSExport doesn't support constructors
3341         https://bugs.webkit.org/show_bug.cgi?id=123380
3342
3343         Reviewed by Geoffrey Garen.
3344
3345         Needed another linked-on-or-after check for when we're deciding whether
3346         we should copy over init family methods.
3347
3348         Factored out the link time checks into a separate function so that they can be cached.
3349
3350         Factored out the check for init-family method selectors into helper function and changed it to
3351         match the description in the clang docs, namely that there can be underscores at the beginning
3352         and the first letter after 'init' part of the selector (if there is one) must be a capital letter.
3353
3354         Updated tests to make sure we don't treat "initialize" as an init-family method and that we do
3355         treat "_init" as an init-family method.
3356
3357         * API/JSWrapperMap.h:
3358         * API/JSWrapperMap.mm:
3359         (isInitFamilyMethod):
3360         (shouldSkipMethodWithName):
3361         (copyMethodsToObject):
3362         (allocateConstructorForCustomClass):
3363         (supportsInitMethodConstructors):
3364         * API/tests/testapi.mm:
3365         (-[ClassA initialize]):
3366         (-[ClassD initialize]):
3367
3368 2013-11-06  Michael Saboff  <msaboff@apple.com>
3369
3370         Change ctiTrampoline into a thunk
3371         https://bugs.webkit.org/show_bug.cgi?id=123844
3372
3373         Reviewed by Filip Pizlo.
3374
3375         Converted ctiTrampoline and ctiOpThrowNotCaught into thunks named callToJavaScript
3376         and returnFromJavaScript.  Cleaned up and in some cases removed JITStubsXXX.h files
3377         after removing ctiTrampoline and ctiOpThrowNotCaught.  Added callJavaScriptJITFunction
3378         to VM that is a function pointer to the callToJavaScript thunk.
3379
3380         * GNUmakefile.list.am:
3381         * JavaScriptCore.xcodeproj/project.pbxproj:
3382         * dfg/DFGDriver.cpp:
3383         (JSC::DFG::compileImpl):
3384         * jit/JITCode.cpp:
3385         (JSC::JITCode::execute):
3386         * jit/JITExceptions.cpp:
3387         (JSC::genericUnwind):
3388         * jit/JITStubs.cpp:
3389         * jit/JITStubs.h:
3390         * jit/JITStubsARM.h:
3391         * jit/JITStubsARM64.h: Removed.
3392         * jit/JITStubsARMv7.h:
3393         * jit/JITStubsMIPS.h: Removed.
3394         * jit/JITStubsMSVC64.asm:
3395         * jit/JITStubsSH4.h: Removed.
3396         * jit/JITStubsX86.h:
3397         * jit/JITStubsX86_64.h:
3398         * jit/JSInterfaceJIT.h:
3399         * jit/ThunkGenerators.cpp:
3400         (JSC::returnFromJavaScript):
3401         (JSC::callToJavaScript):
3402         * jit/ThunkGenerators.h:
3403         * runtime/VM.cpp:
3404         (JSC::VM::VM):
3405         * runtime/VM.h:
3406
3407 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3408
3409         FTL should support StringCharCodeAt
3410         https://bugs.webkit.org/show_bug.cgi?id=123854
3411
3412         Reviewed by Sam Weinig.
3413
3414         * ftl/FTLCapabilities.cpp:
3415         (JSC::FTL::canCompile):
3416         * ftl/FTLLowerDFGToLLVM.cpp:
3417         (JSC::FTL::LowerDFGToLLVM::compileNode):
3418         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
3419
3420 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3421
3422         FTL should support NewObject
3423         https://bugs.webkit.org/show_bug.cgi?id=123849
3424
3425         Reviewed by Oliver Hunt.
3426
3427         * ftl/FTLAbstractHeapRepository.cpp:
3428         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
3429         * ftl/FTLAbstractHeapRepository.h:
3430         * ftl/FTLCapabilities.cpp:
3431         (JSC::FTL::canCompile):
3432         * ftl/FTLIntrinsicRepository.h:
3433         * ftl/FTLLowerDFGToLLVM.cpp:
3434         (JSC::FTL::LowerDFGToLLVM::compileNode):
3435         (JSC::FTL::LowerDFGToLLVM::compileNewObject):
3436         (JSC::FTL::LowerDFGToLLVM::allocate):
3437
3438 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3439
3440         FTL should support StringCharAt
3441         https://bugs.webkit.org/show_bug.cgi?id=123855
3442
3443         Reviewed by Oliver Hunt.
3444         
3445         This is just like GetByVal for String, so we reuse that code.
3446
3447         * ftl/FTLCapabilities.cpp:
3448         (JSC::FTL::canCompile):
3449         * ftl/FTLLowerDFGToLLVM.cpp:
3450         (JSC::FTL::LowerDFGToLLVM::compileNode):
3451         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
3452         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
3453
3454 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3455
3456         Remove old unused code for hypothetical LLVM intrinsics
3457         https://bugs.webkit.org/show_bug.cgi?id=123824
3458
3459         Reviewed by Oliver Hunt.
3460
3461         * ftl/FTLIntrinsicRepository.h:
3462
3463 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3464
3465         FTL should support String character access operations
3466         https://bugs.webkit.org/show_bug.cgi?id=123783
3467
3468         Reviewed by Oliver Hunt.
3469         
3470         Implements:
3471         
3472         - string.length
3473         
3474         - string[index]
3475
3476         * ftl/FTLAbstractHeapRepository.h:
3477         * ftl/FTLCapabilities.cpp:
3478         (JSC::FTL::canCompile):
3479         * ftl/FTLIntrinsicRepository.h:
3480         * ftl/FTLLowerDFGToLLVM.cpp:
3481         (JSC::FTL::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
3482         (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
3483         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
3484
3485 2013-11-05  Mark Hahnenberg  <mhahnenberg@apple.com>
3486
3487         ObjCCallbackFunctionImpl's NSInvocation shouldn't retain its target or arguments
3488         https://bugs.webkit.org/show_bug.cgi?id=123822
3489
3490         Reviewed by Geoffrey Garen.
3491
3492         Using -retainArguments on ObjCCallbackFunctionImpl's NSInvocation leads to memory leaks.
3493         We should handle retaining/releasing the target ourselves, and we should never retain the arguments.
3494
3495         * API/ObjCCallbackFunction.mm:
3496         (JSC::ObjCCallbackFunctionImpl::~ObjCCallbackFunctionImpl):
3497         (JSC::ObjCCallbackFunctionImpl::name):
3498         (objCCallbackFunctionForInvocation):
3499         (objCCallbackFunctionForMethod):
3500         (objCCallbackFunctionForBlock):
3501
3502 2013-11-05  Julien Brianceau  <jbriance@cisco.com>
3503
3504         Fix build for architectures with 4 argument registers (broken since r158681).
3505         https://bugs.webkit.org/show_bug.cgi?id=123826
3506
3507         Reviewed by Michael Saboff.
3508
3509         * jit/CCallHelpers.h:
3510         (JSC::CCallHelpers::setupArgumentsWithExecState):
3511         (JSC::CCallHelpers::setupArguments):
3512
3513 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3514
3515         Fix register allocation inside control flow in GetByVal String
3516         https://bugs.webkit.org/show_bug.cgi?id=123816
3517
3518         Reviewed by Geoffrey Garen.
3519
3520         * dfg/DFGSpeculativeJIT.cpp:
3521         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
3522
3523 2013-11-05  Filip Pizlo  <fpizlo@apple.com>
3524
3525         Remove FTL::LowerDFGToLLVM::compileJSConstant()
3526         https://bugs.webkit.org/show_bug.cgi?id=123817
3527
3528         Reviewed by Geoffrey Garen.
3529
3530         * ftl/FTLLowerDFGToLLVM.cpp:
3531
3532 2013-11-04  Filip Pizlo  <fpizlo@apple.com>
3533
3534         FTL should support PutById
3535         https://bugs.webkit.org/show_bug.cgi?id=123784
3536
3537         Reviewed by Geoffrey Garen.
3538
3539         * ftl/FTLAbbreviations.h:
3540         (JSC::FTL::buildCall):
3541         * ftl/FTLCapabilities.cpp:
3542         (JSC::FTL::canCompile):
3543         * ftl/FTLCompile.cpp:
3544         (JSC::FTL::generateICFastPath):
3545         (JSC::FTL::fixFunctionBasedOnStackMaps):
3546         * ftl/FTLInlineCacheDescriptor.h:
3547         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
3548         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
3549         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
3550         (JSC::FTL::PutByIdDescriptor::ecmaMode):
3551         (JSC::FTL::PutByIdDescriptor::putKind):
3552         * ftl/FTLIntrinsicRepository.h:
3553         * ftl/FTLLowerDFGToLLVM.cpp:
3554         (JSC::FTL::LowerDFGToLLVM::compileNode):
3555         (JSC::FTL::LowerDFGToLLVM::compilePutById):
3556         * ftl/FTLOutput.h:
3557         (JSC::FTL::Output::call):
3558         * ftl/FTLSlowPathCall.cpp:
3559         (JSC::FTL::callOperation):
3560         * ftl/FTLSlowPathCall.h:
3561         * ftl/FTLState.h:
3562         * jit/CCallHelpers.h:
3563         (JSC::CCallHelpers::setupArguments):
3564         * runtime/Executable.h:
3565         (JSC::ScriptExecutable::ecmaMode):
3566
3567 2013-11-04  Filip Pizlo  <fpizlo@apple.com>
3568
3569         GetById->GetByOffset and PutById->PutByOffset folding should mark haveStructures since it may result in structure transition watchpoints
3570         https://bugs.webkit.org/show_bug.cgi?id=123788
3571
3572         Reviewed by Geoffrey Garen.
3573         
3574         haveStructures is true if there are any currentlyKnownStructures that have
3575         interesting values, since that's the only time when clobbering needs to do things.
3576         It's a really important compile-time optimization. But that also means that anytime
3577         we might cause currentlyKnownStructures to get set - like when we might insert some
3578         structure transition watchpoints - we need to set haveStructures. We were forgetting
3579         to do that for GetById->GetByOffset and PutById->PutByOffset because, I guess, we
3580         forgot that those might insert structure transition watchpoints.
3581
3582         * dfg/DFGAbstractInterpreterInlines.h:
3583         (JSC::DFG::::executeEffects):
3584
3585 2013-11-05  Julien Brianceau  <jbriance@cisco.com>
3586
3587         [mips] Make regTx registers match between JSInterfaceJIT and GPRInfo.
3588         https://bugs.webkit.org/show_bug.cgi?id=123807
3589
3590         Reviewed by Mark Lam.
3591
3592         * jit/GPRInfo.h:
3593         (JSC::GPRInfo::toIndex):
3594         * jit/JSInterfaceJIT.h:
3595
3596 2013-11-05  Julien Brianceau  <jbriance@cisco.com>
3597
3598         REGRESSION(r158315): Fix register mixup in JIT::compileOpCall.
3599         https://bugs.webkit.org/show_bug.cgi?id=123799
3600
3601         Reviewed by Mark Lam.
3602
3603         Changeset r158315 is crashing architectures where JSInterfaceJIT::regT3 is
3604         different from GPRInfo::regT3. This is the case for MIPS architecture.
3605
3606         * jit/JITCall32_64.cpp:
3607         (JSC::JIT::compileOpCall):
3608
3609 2013-11-05  Julien Brianceau  <jbriance@cisco.com>
3610
3611         [mips] Fix build for MIPS platforms.
3612         https://bugs.webkit.org/show_bug.cgi?id=123796
3613
3614         Reviewed by Michael Saboff.
3615
3616         * assembler/LinkBuffer.cpp:
3617         (JSC::LinkBuffer::linkCode): Add specific MIPS call to relocateJumps.
3618         * assembler/MIPSAssembler.h: Remove executableCopy (because of r157690) and set relocateJumps function public.
3619         (JSC::MIPSAssembler::firstRegister):
3620         (JSC::MIPSAssembler::lastRegister):
3621         (JSC::MIPSAssembler::firstFPRegister):
3622         (JSC::MIPSAssembler::lastFPRegister):
3623         (JSC::MIPSAssembler::buffer): Needed since r157690.
3624         * assembler/MacroAssemblerMIPS.h: Add framePointerRegister.
3625         (JSC::MacroAssemblerMIPS::revertJumpReplacementToPatchableBranchPtrWithPatch): Remove unused parameter warning.
3626
3627 2013-11-04  Filip Pizlo  <fpizlo@apple.com>
3628
3629         internal-js-tests.yaml/Octane/stress-tests/pdfjs.js.default: ASSERTION FAILED: m_state.forNode(child).m_futurePossibleStructure.isSubsetOf(StructureSet(structure)) at DFGConstantFoldingPhase.cpp:249
3630         https://bugs.webkit.org/show_bug.cgi?id=123778
3631
3632         Unreviewed, remove the other such assertion.
3633
3634         * dfg/DFGConstantFoldingPhase.cpp:
3635         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3636
3637 2013-11-04  Michael Saboff  <msaboff@apple.com>
3638
3639         REGRESSION(r158586): plugins/refcount-leaks.html fails
3640         https://bugs.webkit.org/show_bug.cgi?id=123765
3641
3642         We were leaving a hole of one slot above a new frame when pushing the new frame on
3643         the stack with pushFrame().  This unused slot can contain residual values that will
3644         be marked during GC.
3645
3646         Reviewed by Filip Pizlo.
3647
3648         * interpreter/JSStackInlines.h:
3649         (JSC::JSStack::pushFrame):
3650
3651 2013-11-04  Filip Pizlo  <fpizlo@apple.com>
3652
3653         internal-js-tests.yaml/Octane/stress-tests/pdfjs.js.default: ASSERTION FAILED: m_state.forNode(child).m_futurePossibleStructure.isSubsetOf(StructureSet(structure)) at DFGConstantFoldingPhase.cpp:249
3654         https://bugs.webkit.org/show_bug.cgi?id=123778
3655
3656         Reviewed by Geoffrey Garen.
3657         
3658         This assertion was just wrong: ee do an execute() above the assertion. The assertion
3659         is asserting that if we need a watchpoint (i.e. the best proven structure was not the
3660         current structure) then it must be the future possible structure.  But while that may
3661         have been true before execute(), it won't be true after if the PutById was a
3662         transition. Of course, this can only happen in the concurrent JIT in which case the
3663         code would be invalidated anyway since we would only transform the code in a way that
3664         leveraged the lack of a transition if we inserted a watchpoint, in which case we
3665         would realize that the watchpoint had been fired during compilation.
3666         
3667         Since this requires concurrent JIT awesomeness, I don't know how to test it.
3668
3669         * dfg/DFGConstantFoldingPhase.cpp:
3670         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3671
3672 2013-11-04  Filip Pizlo  <fpizlo@apple.com>
3673
3674         DFG CheckArray(String) should just be a Phantom(String:)
3675         https://bugs.webkit.org/show_bug.cgi?id=123779
3676
3677         Reviewed by Geoffrey Garen.
3678         
3679         This should be a speed-up since Phantom(String:) is smart enough to use the string
3680         structure. It should also be a simplification since CheckArray(String) was totally
3681         redundant.
3682         
3683         Also FixupPhase was assuming that it may see CheckArray's. That's wrong. It can
3684         create CheckArray's but it won't see them as input since no previous phase can
3685         create them.
3686
3687         * dfg/DFGFixupPhase.cpp:
3688         (JSC::DFG::FixupPhase::fixupNode):
3689         (JSC::DFG::FixupPhase::checkArray):
3690         * dfg/DFGSpeculativeJIT.cpp:
3691         (JSC::DFG::SpeculativeJIT::checkArray):
3692
3693 2013-11-04  Filip Pizlo  <fpizlo@apple.com>
3694
3695         DFG NewArray/NewArrayBuffer shouldn't be constructing with negative indexing
3696         https://bugs.webkit.org/show_bug.cgi?id=123760
3697         <rdar://problem/15356705>
3698
3699         Reviewed by Mark Hahnenberg and Oliver Hunt.
3700
3701         * dfg/DFGOperations.cpp:
3702
3703 2013-11-04  Michael Saboff  <msaboff@apple.com>
3704
3705         Eliminate HostCall bit from JSC Stack CallerFrame
3706         https://bugs.webkit.org/show_bug.cgi?id=123642
3707
3708         Reviewed by Geoffrey Garen.
3709
3710         Replace the HostCallFrame bit or'ed to the CallerFrame value in a CallFrame with
3711         a VM entry sentinel CallFrame.  Logically, the VM entry sentinel call frame is
3712         pushed on the stack before the callee frame when calling from native to JavaScript
3713         code.  The callee frame's CallerFrame points at the VM entry sentinel call frame
3714         and the VM entry sentinel call frame's CallerFrame points to the real caller.
3715         The VM entry sentinel call frame has a sentinel (1) in the CodeBlock to indicate
3716         its a VM entry sentinel call frame.  It's ScopeChain has vm.topCallFrame at the
3717         time of the call.  This allows for a complete stack walk as well as walking just
3718         the contiguous JS frames.
3719
3720         The VM entry sentinel call frame and callee frame are currently allocated and
3721         initialized in ExecState::init(), but this initialization will be moved to
3722         ctiTrampoline when we actually move onto the native stack.
3723
3724         * bytecode/CodeBlock.cpp:
3725         (JSC::CodeBlock::noticeIncomingCall):
3726         * debugger/DebuggerCallFrame.cpp:
3727         (JSC::DebuggerCallFrame::callerFrame):
3728         * dfg/DFGJITCompiler.cpp:
3729         (JSC::DFG::JITCompiler::compileExceptionHandlers):
3730         * interpreter/CallFrame.h:
3731         (JSC::ExecState::frameExtent):
3732         (JSC::ExecState::currentVPC):
3733         (JSC::ExecState::setCurrentVPC):
3734         (JSC::ExecState::init):
3735         (JSC::ExecState::noCaller):
3736         (JSC::ExecState::isVMEntrySentinel):
3737         (JSC::ExecState::vmEntrySentinelCallerFrame):
3738         (JSC::ExecState::initializeVMEntrySentinelFrame):
3739         (JSC::ExecState::callerFrameSkippingVMEntrySentinel):
3740         (JSC::ExecState::vmEntrySentinelCodeBlock):
3741         * interpreter/Interpreter.cpp:
3742         (JSC::unwindCallFrame):
3743         (JSC::Interpreter::getStackTrace):
3744         * interpreter/Interpreter.h:
3745         (JSC::TopCallFrameSetter::TopCallFrameSetter):
3746         (JSC::TopCallFrameSetter::~TopCallFrameSetter):
3747         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
3748         * interpreter/JSStack.cpp:
3749         (JSC::JSStack::~JSStack):
3750         * interpreter/JSStackInlines.h:
3751         (JSC::JSStack::getStartOfFrame):
3752         (JSC::JSStack::pushFrame):
3753         (JSC::JSStack::popFrame):
3754         * interpreter/Register.h:
3755         (JSC::Register::operator=):
3756         (JSC::Register::callFrame):
3757         * interpreter/StackVisitor.cpp:
3758         (JSC::StackVisitor::readFrame):
3759         (JSC::StackVisitor::readNonInlinedFrame):
3760         (JSC::StackVisitor::readInlinedFrame):
3761         (JSC::StackVisitor::Frame::print):
3762         * interpreter/VMInspector.cpp:
3763         (JSC::VMInspector::countFrames):
3764         * jit/JIT.cpp:
3765         (JSC::JIT::privateCompileExceptionHandlers):
3766         * jit/JITOperations.cpp:
3767         * jit/JITStubsARM.h:
3768         (JSC::ctiTrampoline):
3769         * jit/JITStubsARM64.h:
3770         * jit/JITStubsARMv7.h:
3771         (JSC::ctiTrampoline):
3772         * jit/JITStubsMIPS.h:
3773         * jit/JITStubsMSVC64.asm:
3774         * jit/JITStubsSH4.h:
3775         * jit/JITStubsX86.h:
3776         * jit/JITStubsX86_64.h:
3777         * jsc.cpp:
3778         (functionDumpCallFrame):
3779         * llint/LowLevelInterpreter.cpp:
3780         (JSC::CLoop::execute):
3781         * runtime/VM.cpp:
3782         (JSC::VM::VM):
3783         (JSC::VM::throwException):
3784
3785 2013-11-04  Mark Hahnenberg  <mhahnenberg@apple.com>
3786
3787         JSArrayBufferViews of length 0 allocate 0 CopiedSpace bytes, which is invalid
3788         https://bugs.webkit.org/show_bug.cgi?id=123746
3789
3790         Reviewed by Geoffrey Garen.
3791
3792         This patch disallows clients from allocating 0 bytes in CopiedSpace. We enforce this invariant 
3793         with an ASSERT in C++ code and a breakpoint in JIT code. Clients who care about 0-byte 
3794         allocations (like JSArrayBufferViews) must handle that case themselves, but we don't punish 
3795         anybody else for the rare case that somebody decides to allocate a 0-length typed array. 
3796         It also makes the allocation and copying cases consistent for CopiedSpace: no 0-byte allocations, 
3797         no 0-byte copying.
3798  
3799         Also added a check so that JSArrayBufferViews don't try to copy their m_vector backing store when 
3800         their length is 0. Also sprinkled several ASSERTs throughout the JSArrayBufferView code to make sure that 
3801         when length is 0 m_vector is null.
3802
3803         * dfg/DFGSpeculativeJIT.cpp:
3804         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
3805         * dfg/DFGSpeculativeJIT.h:
3806         (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage):
3807         * heap/CopiedSpaceInlines.h:
3808         (JSC::CopiedSpace::tryAllocate):
3809         * runtime/ArrayBuffer.h:
3810         (JSC::ArrayBuffer::create):
3811         * runtime/JSArrayBufferView.cpp:
3812         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
3813         * runtime/JSGenericTypedArrayViewInlines.h:
3814         (JSC::::visitChildren):
3815         (JSC::::copyBackingStore):
3816         (JSC::::slowDownAndWasteMemory):
3817
3818 2013-11-04  Julien Brianceau  <jbriance@cisco.com>
3819
3820         [sh4] Refactor jumps in baseline JIT to return label after the jump.
3821         https://bugs.webkit.org/show_bug.cgi?id=123734
3822
3823         Reviewed by Michael Saboff.
3824
3825         Current implementation of jumps in sh4 baseline JIT returns a label on the jump itself
3826         and not after it. This is not correct and leads to issues like infinite loop the DFG
3827         (https://bugs.webkit.org/show_bug.cgi?id=122597 for instance). This refactor fixes this
3828         and also simplifies the link and relink procedures for sh4 jumps.
3829
3830         * assembler/MacroAssemblerSH4.h:
3831         (JSC::MacroAssemblerSH4::branchDouble):
3832         (JSC::MacroAssemblerSH4::branchTrue):
3833         (JSC::MacroAssemblerSH4::branchFalse):
3834         * assembler/SH4Assembler.h:
3835         (JSC::SH4Assembler::jmp):
3836         (JSC::SH4Assembler::extraInstrForBranch):
3837         (JSC::SH4Assembler::jne):
3838         (JSC::SH4Assembler::je):
3839         (JSC::SH4Assembler::bra):
3840         (JSC::SH4Assembler::linkJump):
3841         (JSC::SH4Assembler::relinkJump):
3842
3843 2013-11-03  Filip Pizlo  <fpizlo@apple.com>
3844
3845         Generated color wheel displays incorrectly (regressed in r155567)
3846         https://bugs.webkit.org/show_bug.cgi?id=123664
3847
3848         Reviewed by Andreas Kling.
3849
3850         Interestingly, r155567 just "un-broke" the attempt to constant-fold ArithMod, but
3851         that constant folding was just wrong to begin with. There is no evidence that this
3852         constant folding rule is profitable. I'm removing it instead of trying to think
3853         about what it means for it to be correct.
3854
3855         * dfg/DFGAbstractInterpreterInlines.h:
3856         (JSC::DFG::::executeEffects):
3857
3858 2013-11-03  Filip Pizlo  <fpizlo@apple.com>
3859
3860         Unreviewed, it is no longer necessary to call DisablePrettyStackTrace.
3861
3862         * llvm/library/LLVMExports.cpp:
3863         (initializeAndGetJSCLLVMAPI):
3864
3865 2013-11-02  Mark Lam  <mark.lam@apple.com>
3866
3867         Assertion failure in non-JIT'ed LLInt on ARM Thumb.
3868         https://bugs.webkit.org/show_bug.cgi?id=97569.
3869
3870         Reviewed by Geoffrey Garen.
3871
3872         * assembler/MacroAssemblerCodeRef.h:
3873         - Thumb2 alignment assertions do not apply to the C Loop LLINT because
3874           the arguments passed to those assertions are actually OpcodeIDs
3875           masquerading as addresses.
3876         * llint/LLIntOfflineAsmConfig.h:
3877         - Some of the #defines belong in the !ENABLE(LLINT_C_LOOP) section.
3878           Moving them there.
3879         * llint/LowLevelInterpreter.cpp:
3880         - Keep the compiler happy from some unreferenced C Loop labels.
3881
3882 2013-11-02  Filip Pizlo  <fpizlo@apple.com>
3883
3884         FTL should use LLVM intrinsics for OSR exit, watchpoints, inline caches, and stack layout
3885         https://bugs.webkit.org/show_bug.cgi?id=122318
3886
3887         Reviewed by Geoffrey Garen.
3888         
3889         This all now works. This patch just updates our implementation to work with LLVM trunk,
3890         and removes all of the old code that tried to do OSR exits and heap accesses without
3891         the benefit of those intrinsics.
3892         
3893         In particular:
3894         
3895         - StackMaps parsing now uses the new, less compact, but more future-proof, format.
3896         
3897         - Remove the ftlUsesStackmaps() option and hard-code ftlUsesStackmaps = true. Remove
3898           all code for ftlUsesStackmaps = false, since that was only there for back when we
3899           didn't have the intrinsics.
3900         
3901         - Remove the other experimental OSR options (useLLVMOSRExitIntrinsic,
3902           ftlTrapsOnOSRExit, and FTLOSRExitOmitsMarshalling).
3903         
3904         - Remove LowerDFGToLLVM's use of the ExitThunkGenerator since we don't need to generate
3905           the exit thunks until after we parse the stackmaps.
3906         
3907         - Remove all of the exit thunk and compiler code for the no-stackmaps case.
3908
3909         * dfg/DFGDriver.cpp:
3910         (JSC::DFG::compileImpl):
3911         * ftl/FTLCompile.cpp:
3912         (JSC::FTL::mmAllocateDataSection):
3913         * ftl/FTLExitThunkGenerator.cpp:
3914         (JSC::FTL::ExitThunkGenerator::emitThunk):
3915         * ftl/FTLIntrinsicRepository.h:
3916         * ftl/FTLLocation.cpp:
3917         (JSC::FTL::Location::forStackmaps):
3918         * ftl/FTLLowerDFGToLLVM.cpp:
3919         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
3920         (JSC::FTL::LowerDFGToLLVM::lower):
3921         (JSC::FTL::LowerDFGToLLVM::compileGetById):
3922         (JSC::FTL::LowerDFGToLLVM::compileInvalidationPoint):
3923         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
3924         (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
3925         (JSC::FTL::LowerDFGToLLVM::callStackmap):
3926         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
3927         * ftl/FTLOSRExitCompilationInfo.h:
3928         (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
3929         * ftl/FTLOSRExitCompiler.cpp:
3930         (JSC::FTL::compileStub):
3931         (JSC::FTL::compileFTLOSRExit):
3932         * ftl/FTLStackMaps.cpp:
3933         (JSC::FTL::StackMaps::Location::parse):
3934         (JSC::FTL::StackMaps::parse):
3935         (WTF::printInternal):
3936         * ftl/FTLStackMaps.h:
3937         * ftl/FTLThunks.cpp:
3938         (JSC::FTL::osrExitGenerationThunkGenerator):
3939         * ftl/FTLThunks.h:
3940         (JSC::FTL::Thunks::getOSRExitGenerationThunk):
3941         * runtime/Options.h:
3942
3943 2013-11-02  Patrick Gansterer  <paroga@webkit.org>
3944
3945         Add missing getHostCallReturnValue() for MSVC ARM
3946         https://bugs.webkit.org/show_bug.cgi?id=123685
3947
3948         Reviewed by Darin Adler.
3949
3950         * jit/JITStubsARM.h:
3951
3952 2013-11-02  Patrick Gansterer  <paroga@webkit.org>