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