fourthTier: infrequent segfault in DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks()
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2013-05-16  Mark Hahnenberg  <mhahnenberg@apple.com>
2
3         fourthTier: infrequent segfault in DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks()
4         https://bugs.webkit.org/show_bug.cgi?id=116134
5
6         CodeBlock and JITCode should be ThreadSafeRefCounted. We're going to
7         start using them on more threads very soon (with concurrent
8         compilation). This patch also fixes the specific place where we were
9         superfluously creating a RefPtr.
10
11         Reviewed by Oliver Hunt.
12
13         * bytecode/CodeBlock.h:
14         (JSC::CodeBlock::getJITType):
15         * jit/JITCode.h:
16
17 2013-05-16  Mark Lam  <mark.lam@apple.com>
18
19         Implement a probe mechanism for JIT generated code.
20         https://bugs.webkit.org/show_bug.cgi?id=115705.
21
22         Reviewed by Geoffrey Garen.
23
24         The probe is in the form of a MacroAssembler pseudo instruction.
25         It takes 3 arguments: a ProbeFunction, and 2 void* args.
26
27         When inserted into the JIT at some code generation site, the probe
28         pseudo "instruction" will emit a minimal amount of code to save the
29         stack pointer, 1 (or more) scratch register(s), and the probe
30         arguments into a ProbeContext record on the stack. The emitted code
31         will then call a probe trampoline to do the rest of the work, which
32         consists of:
33         1. saving the remaining registers into the ProbeContext.
34         2. calling the ProbeFunction, and passing it the ProbeContext pointer.
35         3. restoring the registers from the ProbeContext after the ProbeFunction
36            returns, and then returning to the JIT generated code.
37
38         The ProbeContext is stack allocated and is only valid for the duration
39         that the ProbeFunction is executing.
40
41         If the user supplied ProbeFunction alters the register values in the
42         ProbeContext, the new values will be installed into the registers upon
43         returning from the probe. This can be useful for some debugging or
44         testing purposes.
45
46         The probe mechanism is built conditional on USE(MASM_PROBE) which is
47         defined in config.h. USE(MASM_PROBE) will off by default.
48
49         This changeset only implements the probe mechanism for X86 and X86_64.
50
51         * CMakeLists.txt:
52         * GNUmakefile.list.am:
53         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
54         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
55         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
56         * JavaScriptCore.xcodeproj/project.pbxproj:
57         * Target.pri:
58         * assembler/MacroAssembler.h:
59         (MacroAssembler):
60         (JSC::MacroAssembler::shouldBlind):
61         (JSC::MacroAssembler::store32):
62         * assembler/MacroAssemblerX86.h:
63         (MacroAssemblerX86):
64         (JSC::MacroAssemblerX86::trustedImm32FromPtr):
65         (JSC::MacroAssemblerX86::probe):
66         * assembler/MacroAssemblerX86Common.cpp: Added.
67         (JSC::MacroAssemblerX86Common::ProbeContext::dumpCPURegisters):
68         - CPU specific register dumper called by ProbeContext::dump().
69         (JSC::MacroAssemblerX86Common::ProbeContext::dump):
70         - Prints the ProbeContext to the DataLog.
71         * assembler/MacroAssemblerX86Common.h:
72         (MacroAssemblerX86Common):
73         (CPUState): Added.
74         (ProbeContext): Added.
75         * assembler/MacroAssemblerX86_64.h:
76         (MacroAssemblerX86_64):
77         (JSC::MacroAssemblerX86_64::trustedImm64FromPtr):
78         (JSC::MacroAssemblerX86_64::probe):
79         * assembler/X86Assembler.h:
80         * config.h: Added WTF_USE_MASM_PROBE flag.
81         * jit/JITStubs.cpp:
82         * jit/JITStubs.h:
83         * jit/JITStubsX86.h:
84         * jit/JITStubsX86Common.h: Added.
85         * jit/JITStubsX86_64.h:
86
87 2013-05-15  Mark Lam  <mark.lam@apple.com>
88
89         Fix for broken 32-bit build in SpeculativeJIT::checkArray().
90         https://bugs.webkit.org/show_bug.cgi?id=116184.
91
92         Rubber stamped by Mark Hahnenberg.
93
94         * dfg/DFGSpeculativeJIT.cpp:
95         (JSC::DFG::SpeculativeJIT::checkArray):
96
97 2013-05-15  Filip Pizlo  <fpizlo@apple.com>
98
99         fourthTier: DFG should separate link phase into things that must be done concurrently and things that must be done synchronously, and have a way of passing data from one to the other
100         https://bugs.webkit.org/show_bug.cgi?id=116060
101
102         Reviewed by Gavin Barraclough.
103         
104         This introduces the concept of a DFG::Plan, which corresponds to:
105         
106         - The data that the concurrent DFG or FTL need to start compiling a CodeBlock.
107           This mostly includes basic things like CodeBlock*, but also a list of
108           must-handle values for OSR entry.
109         
110         - The data that the synchronous linker need to link in code compiled by a
111           concurrent compilation thread. This is further encapsulated by DFG::Finalizer,
112           since the data, and the actions that need to be taken, are different in DFG
113           versus FTL. This patch also institutes the policy that the concurrent
114           compilation thread shall not use LinkBuffer::performFinalization(), since that
115           code assumes that it's running on the same thread that will actually run the
116           code.
117         
118         - The actions that need to be taken to compile code. In other words, most of the
119           code that previously lived in DFGDriver.cpp now lives in
120           DFG::Plan::compileInThread().
121         
122         - The actions that need to be taken when synchronously linking the code. This
123           includes "really" adding watchpoints and identifiers, checking watchpoint and
124           chain validity, and running the DFG::Finalizer.
125         
126         Currently, DFGDriver just creates a Plan and runs it synchronously. But in the
127         future, we will be able to malloc some Plans and enqueue them, and have the
128         concurrent thread dequeue them and call Plan::compileInThread().
129         
130         For now, this has no behavior or performance change.
131
132         * JavaScriptCore.xcodeproj/project.pbxproj:
133         * assembler/LinkBuffer.cpp:
134         (JSC::LinkBuffer::performFinalization):
135         * assembler/LinkBuffer.h:
136         (LinkBuffer):
137         (JSC::LinkBuffer::LinkBuffer):
138         (JSC::LinkBuffer::~LinkBuffer):
139         * dfg/DFGAbstractState.cpp:
140         (JSC::DFG::AbstractState::initialize):
141         (JSC::DFG::AbstractState::executeEffects):
142         * dfg/DFGAbstractValue.cpp:
143         (JSC::DFG::AbstractValue::setFuturePossibleStructure):
144         (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
145         * dfg/DFGByteCodeParser.cpp:
146         (JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
147         (JSC::DFG::ByteCodeParser::handleGetById):
148         (JSC::DFG::ByteCodeParser::parseResolveOperations):
149         (JSC::DFG::ByteCodeParser::parseBlock):
150         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
151         (JSC::DFG::ByteCodeParser::parseCodeBlock):
152         * dfg/DFGConstantFoldingPhase.cpp:
153         (JSC::DFG::ConstantFoldingPhase::foldConstants):
154         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
155         * dfg/DFGDriver.cpp:
156         (DFG):
157         (JSC::DFG::compile):
158         * dfg/DFGFailedFinalizer.cpp: Added.
159         (DFG):
160         (JSC::DFG::FailedFinalizer::FailedFinalizer):
161         (JSC::DFG::FailedFinalizer::~FailedFinalizer):
162         (JSC::DFG::FailedFinalizer::finalize):
163         (JSC::DFG::FailedFinalizer::finalizeFunction):
164         * dfg/DFGFailedFinalizer.h: Added.
165         (DFG):
166         (FailedFinalizer):
167         * dfg/DFGFinalizer.cpp: Added.
168         (DFG):
169         (JSC::DFG::Finalizer::Finalizer):
170         (JSC::DFG::Finalizer::~Finalizer):
171         * dfg/DFGFinalizer.h: Added.
172         (DFG):
173         (Finalizer):
174         * dfg/DFGFixupPhase.cpp:
175         (JSC::DFG::FixupPhase::fixupNode):
176         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
177         * dfg/DFGGraph.cpp:
178         (JSC::DFG::Graph::Graph):
179         (JSC::DFG::Graph::dump):
180         (DFG):
181         * dfg/DFGGraph.h:
182         (Graph):
183         (JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
184         (JSC::DFG::Graph::compilation):
185         (JSC::DFG::Graph::identifiers):
186         (JSC::DFG::Graph::watchpoints):
187         (JSC::DFG::Graph::chains):
188         * dfg/DFGJITCompiler.cpp:
189         (JSC::DFG::JITCompiler::linkOSRExits):
190         (JSC::DFG::JITCompiler::link):
191         (JSC::DFG::JITCompiler::compile):
192         (JSC::DFG::JITCompiler::compileFunction):
193         (JSC::DFG::JITCompiler::linkFunction):
194         (DFG):
195         (JSC::DFG::JITCompiler::disassemble):
196         * dfg/DFGJITCompiler.h:
197         (JITCompiler):
198         (JSC::DFG::JITCompiler::addLazily):
199         * dfg/DFGJITFinalizer.cpp: Added.
200         (DFG):
201         (JSC::DFG::JITFinalizer::JITFinalizer):
202         (JSC::DFG::JITFinalizer::~JITFinalizer):
203         (JSC::DFG::JITFinalizer::finalize):
204         (JSC::DFG::JITFinalizer::finalizeFunction):
205         (JSC::DFG::JITFinalizer::finalizeCommon):
206         * dfg/DFGJITFinalizer.h: Added.
207         (DFG):
208         (JITFinalizer):
209         * dfg/DFGPlan.cpp: Added.
210         (DFG):
211         (JSC::DFG::dumpAndVerifyGraph):
212         (JSC::DFG::Plan::Plan):
213         (JSC::DFG::Plan::~Plan):
214         (JSC::DFG::Plan::compileInThread):
215         (JSC::DFG::Plan::isStillValid):
216         (JSC::DFG::Plan::reallyAdd):
217         (JSC::DFG::Plan::finalize):
218         * dfg/DFGPlan.h: Added.
219         (DFG):
220         (Plan):
221         (JSC::DFG::Plan::vm):
222         * dfg/DFGPredictionInjectionPhase.cpp:
223         (JSC::DFG::PredictionInjectionPhase::run):
224         * dfg/DFGSpeculativeJIT.h:
225         (JSC::DFG::SpeculativeJIT::identifierUID):
226         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
227         * dfg/DFGTypeCheckHoistingPhase.cpp:
228         (JSC::DFG::TypeCheckHoistingPhase::run):
229         * ftl/FTLGeneratedFunction.h: Added.
230         (FTL):
231         * ftl/FTLJITFinalizer.cpp: Added.
232         (FTL):
233         (JSC::FTL::JITFinalizer::JITFinalizer):
234         (JSC::FTL::JITFinalizer::~JITFinalizer):
235         (JSC::FTL::JITFinalizer::finalize):
236         (JSC::FTL::JITFinalizer::finalizeFunction):
237         * ftl/FTLJITFinalizer.h: Added.
238         (FTL):
239         (JITFinalizer):
240         (JSC::FTL::JITFinalizer::initializeExitThunksLinkBuffer):
241         (JSC::FTL::JITFinalizer::initializeEntrypointLinkBuffer):
242         (JSC::FTL::JITFinalizer::initializeCode):
243         (JSC::FTL::JITFinalizer::initializeFunction):
244         (JSC::FTL::JITFinalizer::initializeArityCheck):
245         (JSC::FTL::JITFinalizer::initializeJITCode):
246         * ftl/FTLLink.cpp:
247         (JSC::FTL::link):
248         * ftl/FTLLink.h:
249         (FTL):
250         * ftl/FTLLowerDFGToLLVM.cpp:
251         (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
252         * ftl/FTLState.cpp:
253         (JSC::FTL::State::State):
254         * ftl/FTLState.h:
255         (FTL):
256         (State):
257
258 2013-05-14  Mark Lam  <mark.lam@apple.com>
259
260         Refactor JITStubs.cpp to move CPU specific parts out into their own files.
261         https://bugs.webkit.org/show_bug.cgi?id=116135.
262
263         Reviewed by Michael Saboff.
264
265         This mod only moves the CPU specific parts out. There is no code change.
266         Tested on debug builds of X86, X86_64, ARM and ARMv7. The SH4 and MIPS
267         ports are untested. Windows port also not tested.
268
269         * GNUmakefile.list.am:
270         * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj:
271         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
272         * JavaScriptCore.xcodeproj/project.pbxproj:
273         * jit/JITStubs.cpp:
274         (JSC::performPlatformSpecificJITAssertions):
275         * jit/JITStubsARM.h: Added.
276         (JSC::ctiTrampoline):
277         (JSC::ctiTrampolineEnd):
278         (JSC::ctiVMThrowTrampoline):
279         (JSC::ctiOpThrowNotCaught):
280         (JSC::performARMJITAssertions):
281         * jit/JITStubsARMv7.h: Added.
282         (JSC::ctiTrampoline):
283         (JSC::ctiVMThrowTrampoline):
284         (JSC::ctiOpThrowNotCaught):
285         (JSC::performARMv7JITAssertions):
286         * jit/JITStubsMIPS.h: Added.
287         (JSC::performMIPSJITAssertions):
288         * jit/JITStubsSH4.h: Added.
289         * jit/JITStubsX86.h: Added.
290         * jit/JITStubsX86_64.h: Added.
291
292 2013-05-14  Mark Hahnenberg  <mhahnenberg@apple.com>
293
294         fourthTier: Segfault in jsc with simple test program when running with profile dumping enabled
295         https://bugs.webkit.org/show_bug.cgi?id=116082
296
297         It's crashing because CodeBlock::baselineVersion() doesn't know how to handle the case where 'this' is the 
298         baseline version but it hasn't been assigned to the m_blahCodeBlock field in BlahExecutable. The fix is to 
299         check if we're the baseline version in baselineVersion() and return this if so.
300
301         Reviewed by Filip Pizlo.
302
303         * bytecode/CodeBlock.h:
304         (JSC::CodeBlock::baselineVersion):
305
306 2013-05-11  Mark Hahnenberg  <mhahnenberg@apple.com>
307
308         Rename StructureCheckHoistingPhase to TypeCheckHoistingPhase
309         https://bugs.webkit.org/show_bug.cgi?id=115938
310
311         We're going to add some more types of check hoisting soon, so let's have
312         the right name here.
313
314         Rubber stamped by Filip Pizlo.
315
316         * CMakeLists.txt:
317         * GNUmakefile.list.am:
318         * JavaScriptCore.xcodeproj/project.pbxproj:
319         * Target.pri:
320         * dfg/DFGDriver.cpp:
321         (JSC::DFG::compile):
322         * dfg/DFGStructureCheckHoistingPhase.cpp: Removed.
323         * dfg/DFGStructureCheckHoistingPhase.h: Removed.
324         * dfg/DFGTypeCheckHoistingPhase.cpp: Added.
325         (DFG):
326         (TypeCheckHoistingPhase):
327         (JSC::DFG::TypeCheckHoistingPhase::TypeCheckHoistingPhase):
328         (JSC::DFG::TypeCheckHoistingPhase::run):
329         (JSC::DFG::TypeCheckHoistingPhase::shouldConsiderForHoisting):
330         (JSC::DFG::TypeCheckHoistingPhase::noticeStructureCheck):
331         (CheckData):
332         (JSC::DFG::TypeCheckHoistingPhase::CheckData::CheckData):
333         (JSC::DFG::performTypeCheckHoisting):
334         * dfg/DFGTypeCheckHoistingPhase.h: Added.
335
336 2013-05-10  Mark Hahnenberg  <mhahnenberg@apple.com>
337
338         SpeculativeJIT::checkArray should use the correct ExitKind
339         https://bugs.webkit.org/show_bug.cgi?id=115943
340
341         Currently it uses Uncountable, which gives us no information if we end up exiting due to a 
342         mismatched ClassInfo pointer. It should instead use BadType and should pass the correct 
343         JSValueSource and Node instead of passing empty values.
344
345         Reviewed by Filip Pizlo.
346
347         * dfg/DFGSpeculativeJIT.cpp:
348         (JSC::DFG::SpeculativeJIT::checkArray):
349
350 2013-05-11  Filip Pizlo  <fpizlo@apple.com>
351
352         fourthTier: FTL should support Jump and ForceOSRExit
353         https://bugs.webkit.org/show_bug.cgi?id=115942
354
355         Reviewed by Oliver Hunt.
356         
357         Added two obvious nodes: Jump and ForceOSRExit. We already had everything we needed
358         to support them.
359         
360         Adding these increases our coverage a fair bit, and revealed a bug: LLVM's full
361         instruction selector currently appears to mishandle doubles in constant pools (or
362         just constant pools in general) with the small code model in the MCJIT. But switching
363         to FastISel "fixes" it. That's what this patch does, for now. This will probably
364         actually be permanent; the FastISel does pretty much everything we would ever want,
365         at least in the foreseeable future.
366
367         * ftl/FTLCapabilities.cpp:
368         (JSC::FTL::canCompile):
369         (FTL):
370         * ftl/FTLCompile.cpp:
371         (JSC::FTL::compile):
372         * ftl/FTLLowerDFGToLLVM.cpp:
373         (JSC::FTL::LowerDFGToLLVM::compileBlock):
374         (JSC::FTL::LowerDFGToLLVM::compileNode):
375         (JSC::FTL::LowerDFGToLLVM::compileJSConstant):
376         (LowerDFGToLLVM):
377         (JSC::FTL::LowerDFGToLLVM::compileJump):
378         (JSC::FTL::LowerDFGToLLVM::compileReturn):
379         (JSC::FTL::LowerDFGToLLVM::compileForceOSRExit):
380         * runtime/Options.h:
381         (JSC):
382
383 >>>>>>> .r149942
384 2013-05-10  Filip Pizlo  <fpizlo@apple.com>
385
386         fourthTier: FTL should support CompareStrictEqConstant
387         https://bugs.webkit.org/show_bug.cgi?id=115941
388
389         Reviewed by Mark Hahnenberg.
390         
391         Pretty simple, but factors out the craziness of comparing against null or undefined
392         in a way that is reusable for both == and ===.
393
394         * ftl/FTLCapabilities.cpp:
395         (JSC::FTL::canCompile):
396         * ftl/FTLLowerDFGToLLVM.cpp:
397         (JSC::FTL::LowerDFGToLLVM::compileNode):
398         (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
399         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEqConstant):
400         (LowerDFGToLLVM):
401         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
402
403 2013-05-10  Filip Pizlo  <fpizlo@apple.com>
404
405         fourthTier: FTL should support CompareEqConstant
406         https://bugs.webkit.org/show_bug.cgi?id=115939
407
408         Reviewed by Oliver Hunt and Mark Hahnenberg.
409         
410         The most interesting part of this patch is the way I make it easier to deal with
411         the inputs to Phi functions. This adds the notion of ValueFromBlock, which you
412         can get by doing m_out.anchor(value). You can build up a vector of these, and then
413         pass them to m_out.phi(type, vector) in one go.
414
415         * JavaScriptCore.xcodeproj/project.pbxproj:
416         * ftl/FTLAbbreviatedTypes.h: Added.
417         (FTL):
418         * ftl/FTLAbbreviations.h:
419         (FTL):
420         (JSC::FTL::addIncoming):
421         (JSC::FTL::buildPhi):
422         * ftl/FTLAbstractHeapRepository.h:
423         (FTL):
424         * ftl/FTLCapabilities.cpp:
425         (JSC::FTL::canCompile):
426         * ftl/FTLLowerDFGToLLVM.cpp:
427         (JSC::FTL::LowerDFGToLLVM::compileNode):
428         (JSC::FTL::LowerDFGToLLVM::compileCompareEqConstant):
429         (LowerDFGToLLVM):
430         (JSC::FTL::LowerDFGToLLVM::lowDouble):
431         (JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
432         * ftl/FTLOutput.h:
433         (JSC::FTL::Output::phi):
434         (Output):
435         (JSC::FTL::Output::anchor):
436         * ftl/FTLValueFromBlock.h: Added.
437         (FTL):
438         (ValueFromBlock):
439         (JSC::FTL::ValueFromBlock::ValueFromBlock):
440         (JSC::FTL::ValueFromBlock::value):
441         (JSC::FTL::ValueFromBlock::block):
442
443 2013-05-10  Filip Pizlo  <fpizlo@apple.com>
444
445         fourthTier: FTL should support CompareStrictEq
446         https://bugs.webkit.org/show_bug.cgi?id=115927
447
448         Reviewed by Mark Hahnenberg.
449         
450         Do the sensible thing, and make it so that for common cases, CompareEq is
451         implemented in terms of CompareStrictEq in the FTL backend. All of the cases
452         we currently support can be done this way.
453
454         * ftl/FTLCapabilities.cpp:
455         (JSC::FTL::canCompile):
456         * ftl/FTLLowerDFGToLLVM.cpp:
457         (JSC::FTL::LowerDFGToLLVM::compileNode):
458         (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
459         (LowerDFGToLLVM):
460         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
461
462 2013-05-10  Filip Pizlo  <fpizlo@apple.com>
463
464         fourthTier: FTL should support Int32ToDouble
465         https://bugs.webkit.org/show_bug.cgi?id=115926
466
467         Reviewed by Mark Hahnenberg.
468         
469         This node exists mainly to help the DFG see that a node may have both an int
470         and a double representation. But in the FTL, nodes already have multiple
471         representations. So this is just a no-op for the FTL.
472         
473         I considered making it so that the node isn't even inserted if we're doing
474         FTL compilation, but that would have required a bunch of conditionalizing in
475         the DFG's optimization phases, which sort of expect this node to be present
476         and necessary.
477
478         * ftl/FTLCapabilities.cpp:
479         (JSC::FTL::canCompile):
480         * ftl/FTLLowerDFGToLLVM.cpp:
481         (JSC::FTL::LowerDFGToLLVM::compileNode):
482         (JSC::FTL::LowerDFGToLLVM::compileInt32ToDouble):
483         (LowerDFGToLLVM):
484
485 2013-05-10  Filip Pizlo  <fpizlo@apple.com>
486
487         fourthTier: FTL should support LogicalNot
488         https://bugs.webkit.org/show_bug.cgi?id=115924
489
490         Reviewed by Mark Hahnenberg.
491
492         * ftl/FTLAbbreviations.h:
493         (JSC::FTL::buildNot):
494         * ftl/FTLCapabilities.cpp:
495         (JSC::FTL::canCompile):
496         * ftl/FTLLowerDFGToLLVM.cpp:
497         (JSC::FTL::LowerDFGToLLVM::compileNode):
498         (JSC::FTL::LowerDFGToLLVM::compileLogicalNot):
499         (LowerDFGToLLVM):
500         * ftl/FTLOutput.h:
501         (JSC::FTL::Output::bitNot):
502
503 2013-05-10  Filip Pizlo  <fpizlo@apple.com>
504
505         fourthTier: FTL should support CompareGreater, CompareLessEq, and CompareGreaterEq
506         https://bugs.webkit.org/show_bug.cgi?id=115923
507
508         Reviewed by Mark Hahnenberg.
509         
510         Also fixed a bug where double CompareLess would assert.
511
512         * ftl/FTLCapabilities.cpp:
513         (JSC::FTL::canCompile):
514         * ftl/FTLLowerDFGToLLVM.cpp:
515         (JSC::FTL::LowerDFGToLLVM::compileNode):
516         (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
517         (LowerDFGToLLVM):
518         (JSC::FTL::LowerDFGToLLVM::compileCompareLessEq):
519         (JSC::FTL::LowerDFGToLLVM::compileCompareGreater):
520         (JSC::FTL::LowerDFGToLLVM::compileCompareGreaterEq):
521
522 2013-05-10  Filip Pizlo  <fpizlo@apple.com>
523
524         fourthTier: FTL CompareEq ObjectUse should handle masquerading
525         https://bugs.webkit.org/show_bug.cgi?id=115920
526
527         Reviewed by Mark Hahnenberg.
528         
529         We don't yet support watchpoints, but this does all the wiring right up to the
530         part where we would have emitted watchpoints. I've also written this in a way that
531         makes it easy to use the case where you would have anyway speculated non-masquerading
532         even if the watchpoint was invalidated.
533         
534         This is inherently racy, of course: but the only race here is that you might first
535         set the watchpoint, and then the watchpoint is invalidated, and then you compile rest
536         of the code in a way that doesn't need the watchpoint. That's fine, since the FTL
537         will remember that it had set the watchpoint and then cancel the compilation.
538
539         * ftl/FTLAbbreviations.h:
540         (JSC::FTL::int8Type):
541         * ftl/FTLAbstractHeapRepository.h:
542         (FTL):
543         * ftl/FTLCommonValues.cpp:
544         (JSC::FTL::CommonValues::CommonValues):
545         * ftl/FTLCommonValues.h:
546         (CommonValues):
547         * ftl/FTLLowerDFGToLLVM.cpp:
548         (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
549         (JSC::FTL::LowerDFGToLLVM::lowNonNullObject):
550         (LowerDFGToLLVM):
551         (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
552         (JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
553         (JSC::FTL::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIfIsStillValid):
554         * ftl/FTLOutput.h:
555         (JSC::FTL::Output::constInt8):
556         (JSC::FTL::Output::load8):
557         (JSC::FTL::Output::isZero8):
558         (JSC::FTL::Output::notZero8):
559         (JSC::FTL::Output::testIsZero8):
560         (JSC::FTL::Output::testNonZero8):
561
562 2013-05-09  Filip Pizlo  <fpizlo@apple.com>
563
564         fourthTier: DFG shouldn't allocate in the GC heap
565         https://bugs.webkit.org/show_bug.cgi?id=115598
566
567         Reviewed by Geoffrey Garen.
568         
569         I believe that we've now fixed this, and this patch just adds the relevant assertion.
570
571         * runtime/JSCellInlines.h:
572         (JSC::JSCell::JSCell):
573
574 2013-05-09  Filip Pizlo  <fpizlo@apple.com>
575
576         fourthTier: CodeBlock should be RefCounted
577         https://bugs.webkit.org/show_bug.cgi?id=115594
578
579         Reviewed by Geoffrey Garen.
580         
581         This makes it possible to have the currently-being-compiled CodeBlock not be
582         installed in Executable, while also allowing it to point to its intended
583         alternative(). So long as we were using ownership and not reference counting, it
584         would have been difficult to have both CodeBlock::m_alternative and
585         Executable::m_codeBlockForBlah point to the previous CodeBlock.
586         
587         I also took the opportunity to clean up a bunch of code that appears to have
588         rotted.
589
590         * assembler/MacroAssemblerCodeRef.h:
591         (MacroAssemblerCodePtr):
592         (JSC::MacroAssemblerCodePtr::operator==):
593         * bytecode/CodeBlock.cpp:
594         (JSC::CodeBlock::CodeBlock):
595         * bytecode/CodeBlock.h:
596         (JSC::CodeBlock::releaseAlternative):
597         (JSC::CodeBlock::setAlternative):
598         (CodeBlock):
599         (JSC::GlobalCodeBlock::GlobalCodeBlock):
600         (JSC::ProgramCodeBlock::ProgramCodeBlock):
601         (JSC::EvalCodeBlock::EvalCodeBlock):
602         (JSC::FunctionCodeBlock::FunctionCodeBlock):
603         * heap/DFGCodeBlocks.cpp:
604         (JSC::DFGCodeBlocks::~DFGCodeBlocks):
605         (JSC::DFGCodeBlocks::jettison):
606         (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
607         * heap/DFGCodeBlocks.h:
608         (DFGCodeBlocks):
609         * heap/Heap.cpp:
610         (JSC::Heap::jettisonDFGCodeBlock):
611         * heap/Heap.h:
612         * jit/JITDriver.h:
613         (JSC::jitCompileIfAppropriate):
614         (JSC::jitCompileFunctionIfAppropriate):
615         * runtime/Executable.cpp:
616         (JSC::jettisonCodeBlock):
617         (JSC::EvalExecutable::jitCompile):
618         (JSC::EvalExecutable::compileInternal):
619         (JSC::ProgramExecutable::jitCompile):
620         (JSC::ProgramExecutable::compileInternal):
621         (JSC::FunctionExecutable::jitCompileForCall):
622         (JSC::FunctionExecutable::jitCompileForConstruct):
623         (JSC::FunctionExecutable::produceCodeBlockFor):
624         (JSC::FunctionExecutable::compileForCallInternal):
625         (JSC::FunctionExecutable::compileForConstructInternal):
626         * runtime/Executable.h:
627         (EvalExecutable):
628         (FunctionExecutable):
629         (JSC::FunctionExecutable::codeBlockFor):
630         * runtime/ExecutionHarness.h:
631         (JSC::prepareForExecution):
632         (JSC::prepareFunctionForExecution):
633
634 2013-05-09  Filip Pizlo  <fpizlo@apple.com>
635
636         fourthTier: DFG should have its own notion of StructureChain, and it should be possible to validate it after compilation finishes
637         https://bugs.webkit.org/show_bug.cgi?id=115841
638
639         Reviewed by Oliver Hunt.
640         
641         This adds IntendedStructureChain, which is like StructureChain, except that it holds a bit
642         more information and can be validated independantly of its owning Structure and lexical
643         GlobalObject, since it remembers both of those things. It's also malloc'd and RefCounted
644         rather than GC'd, so it can be allocated in a concurrent compilation thread.
645         
646         Gave this class a bunch of methods to allow the following idiom:
647         
648         - Snapshot a structure chain concurrently. This structure chain may end up being
649           wrong in case of races, but in that case we will find out when we try to validate
650           it.
651         
652         - Perform validation on the structure chain itself, without recomputing the chain.
653           Previously, many chain validation methods (prototypeChainMayInterceptStoreTo() for
654           example) recomputed the chain, and hence, were inherently racy: you could build one
655           chain and then validate against a different chain, and hence not realize that the
656           chain you did build was actually broken for your purposes, because the chain you
657           checked was a different one.
658         
659         - Validate that the chain is still the right one at any time, allowing the cancellation
660           of compilation if there was a race.
661         
662         Also added DFG::DesiredStructureChains, which tracks those intended structure chains that
663         the compiler had already chosen to use. If any of those are invalid at link time, throw
664         out the compilation.
665
666         * JavaScriptCore.xcodeproj/project.pbxproj:
667         * bytecode/GetByIdStatus.cpp:
668         (JSC::GetByIdStatus::computeForChain):
669         (JSC::GetByIdStatus::computeFor):
670         * bytecode/GetByIdStatus.h:
671         (JSC::GetByIdStatus::GetByIdStatus):
672         (JSC::GetByIdStatus::chain):
673         (GetByIdStatus):
674         * bytecode/PutByIdStatus.cpp:
675         (JSC::PutByIdStatus::computeFromLLInt):
676         (JSC::PutByIdStatus::computeFor):
677         * bytecode/PutByIdStatus.h:
678         (JSC::PutByIdStatus::PutByIdStatus):
679         (JSC::PutByIdStatus::structureChain):
680         (PutByIdStatus):
681         * dfg/DFGAbstractState.cpp:
682         (JSC::DFG::AbstractState::executeEffects):
683         * dfg/DFGByteCodeParser.cpp:
684         (JSC::DFG::ByteCodeParser::handleGetById):
685         (JSC::DFG::ByteCodeParser::parseBlock):
686         * dfg/DFGConstantFoldingPhase.cpp:
687         (JSC::DFG::ConstantFoldingPhase::foldConstants):
688         * dfg/DFGDesiredStructureChains.cpp: Added.
689         (DFG):
690         (JSC::DFG::DesiredStructureChains::DesiredStructureChains):
691         (JSC::DFG::DesiredStructureChains::~DesiredStructureChains):
692         (JSC::DFG::DesiredStructureChains::areStillValid):
693         * dfg/DFGDesiredStructureChains.h: Added.
694         (DFG):
695         (DesiredStructureChains):
696         (JSC::DFG::DesiredStructureChains::addLazily):
697         * dfg/DFGGraph.cpp:
698         (JSC::DFG::Graph::isStillValid):
699         (DFG):
700         * dfg/DFGGraph.h:
701         (Graph):
702         * dfg/DFGJITCompiler.cpp:
703         (JSC::DFG::JITCompiler::link):
704         (JSC::DFG::JITCompiler::linkFunction):
705         * ftl/FTLLink.cpp:
706         (JSC::FTL::link):
707         * runtime/IntendedStructureChain.cpp: Added.
708         (JSC):
709         (JSC::IntendedStructureChain::IntendedStructureChain):
710         (JSC::IntendedStructureChain::~IntendedStructureChain):
711         (JSC::IntendedStructureChain::isStillValid):
712         (JSC::IntendedStructureChain::matches):
713         (JSC::IntendedStructureChain::chain):
714         (JSC::IntendedStructureChain::mayInterceptStoreTo):
715         (JSC::IntendedStructureChain::isNormalized):
716         (JSC::IntendedStructureChain::terminalPrototype):
717         * runtime/IntendedStructureChain.h: Added.
718         (JSC):
719         (IntendedStructureChain):
720         (JSC::IntendedStructureChain::head):
721         (JSC::IntendedStructureChain::size):
722         (JSC::IntendedStructureChain::at):
723         (JSC::IntendedStructureChain::operator[]):
724         (JSC::IntendedStructureChain::last):
725         * runtime/Structure.cpp:
726         (JSC::Structure::prototypeChainMayInterceptStoreTo):
727         * runtime/Structure.h:
728         (Structure):
729         * runtime/StructureInlines.h:
730         (JSC::Structure::storedPrototypeObject):
731         (JSC):
732         (JSC::Structure::storedPrototypeStructure):
733
734 2013-05-06  Mark Lam  <mark.lam@apple.com>
735
736         Fix broken 32-bit build + some clean up in JITStubs.cpp.
737         https://bugs.webkit.org/show_bug.cgi?id=115684.
738
739         Reviewed by Geoffrey Garen.
740
741         * dfg/DFGSpeculativeJIT32_64.cpp:
742         (JSC::DFG::SpeculativeJIT::compile):
743         * jit/JITStubs.cpp:
744         - removed unneeded stubs for CPU(X86_64) && USE(JSVALUE32_64).
745         - added some line breaks to more clearly delineate between
746           ports/configurations of stub code.
747
748 2013-05-05  Geoffrey Garen  <ggaren@apple.com>
749
750         Rolled back in r149527 with crash fixed.
751
752         Reviewed by Oliver Hunt.
753
754             Rationalized 'this' value conversion
755             https://bugs.webkit.org/show_bug.cgi?id=115542
756
757             This fixes a bunch of Sputnik tests, and some bad pointer access.
758
759             The new model is that the callee always performs 'this' value conversion.
760
761             My ultimate goal is to break up resolve_with_this into single-result 
762             opcodes. This step avoids having to add a special form of convert_this
763             that distinguishes callers vs callees.
764
765             Only the callee knows whether it uses 'this' and/or whether 'this'
766             conversion should use StrictMode, so it's most natural to perform
767             convert_this in the callee. 
768
769             * API/JSCallbackFunction.cpp:
770             (JSC::JSCallbackFunction::call): Perform 'this' value conversion for
771             our callee, since it may observe 'this'.
772
773             * API/JSCallbackObjectFunctions.h:
774             (JSC::::call): Ditto.
775
776             * API/JSContextRef.cpp:
777             (JSGlobalContextCreateInGroup): Use a proxy 'this' object in global scope
778             even when we're not in the browser. This eliminates some odd cases where
779             API clients used to be able to get a direct reference to an environment
780             record. Now, any reference to an environment record unambiguously means
781             that the VM resolved that record in the scope chain.
782
783             (JSContextGetGlobalObject): Removed an incorrect comment. Now that JSC
784             participates in the proxy 'this' object scheme, the behavior is not
785             WebCore-only.
786
787             * API/JSObjectRef.cpp:
788             (JSObjectSetPrototype):
789             (JSObjectCallAsFunction): Don't perform 'this' value conversion in the
790             caller; the callee will do it if needed.
791
792             * JavaScriptCore.order: Order!
793
794             * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
795             * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
796             What are the chances that this will work?
797
798             * bytecode/CodeBlock.cpp:
799             (JSC::CodeBlock::dumpBytecode):
800             (JSC::CodeBlock::CodeBlock): Renamed convert_this to to_this, to match our
801             other conversion opcodes.
802
803             * bytecode/CodeOrigin.h:
804             (CodeOrigin):
805             (InlineCallFrame):
806             (JSC::CodeOrigin::codeOriginOwner): Use the more precise type for our
807             executable, so compilation can discover where we're in strict mode.
808
809             * bytecode/Opcode.h:
810             (JSC::padOpcodeName): Updated for rename.
811
812             * bytecompiler/BytecodeGenerator.cpp:
813             (JSC::BytecodeGenerator::BytecodeGenerator): Always emit to_this when
814             'this' is in use -- strict mode still needs to convert environment
815             records to 'undefined'.
816
817             * dfg/DFGAbstractState.cpp:
818             (JSC::DFG::AbstractState::executeEffects):
819             * dfg/DFGByteCodeParser.cpp:
820             (JSC::DFG::ByteCodeParser::parseBlock):
821             * dfg/DFGCapabilities.h:
822             (JSC::DFG::canCompileOpcode): Updated for renames.
823
824             * dfg/DFGFixupPhase.cpp:
825             (JSC::DFG::FixupPhase::fixupNode): Tightened up this code to consider
826             strict mode (a new requirement) and to consider the global object (which
827             was always a requirement).
828
829             * dfg/DFGGraph.h:
830             (JSC::DFG::Graph::globalThisObjectFor):
831             (JSC::DFG::Graph::executableFor):
832             * dfg/DFGNodeType.h:
833             * dfg/DFGOperations.cpp:
834             * dfg/DFGOperations.h:
835             * dfg/DFGPredictionPropagationPhase.cpp:
836             (JSC::DFG::PredictionPropagationPhase::propagate):
837             * dfg/DFGSpeculativeJIT32_64.cpp:
838             (JSC::DFG::SpeculativeJIT::compile):
839             * dfg/DFGSpeculativeJIT64.cpp:
840             (JSC::DFG::SpeculativeJIT::compile): Ditto.
841
842             * interpreter/Interpreter.cpp:
843             (JSC::eval):
844             (JSC::Interpreter::execute):
845             (JSC::Interpreter::executeCall):
846             * interpreter/Interpreter.h: Don't ASSERT about 'this' -- it's our job
847             to fix it up if needed.
848
849             * jit/JIT.cpp:
850             (JSC::JIT::privateCompileMainPass):
851             (JSC::JIT::privateCompileSlowCases):
852             * jit/JIT.h:
853             (JIT):
854             * jit/JITOpcodes.cpp:
855             (JSC::JIT::emit_op_to_this):
856             (JSC::JIT::emitSlow_op_to_this):
857             * jit/JITOpcodes32_64.cpp:
858             (JSC::JIT::emit_op_to_this):
859             (JSC::JIT::emitSlow_op_to_this):
860             * jit/JITStubs.cpp:
861             (JSC::DEFINE_STUB_FUNCTION):
862             * jit/JITStubs.h: Removed special-case code for various kinds of
863             conversions. The baseline fast path is now final objects only. It hurt
864             my brain to think through how to keep the other fast paths working, and
865             our benchmarks do not object.
866
867             * llint/LLIntData.cpp:
868             (JSC::LLInt::Data::performAssertions):
869             * llint/LLIntSlowPaths.cpp:
870             (JSC::LLInt::LLINT_SLOW_PATH_DECL):
871             * llint/LLIntSlowPaths.h:
872             (LLInt):
873             * llint/LowLevelInterpreter.asm:
874             * llint/LowLevelInterpreter32_64.asm:
875             * llint/LowLevelInterpreter64.asm: Updated for renames. Removed some
876             special case code, as in the JIT above.
877
878             * profiler/ProfileGenerator.cpp:
879             (JSC::ProfileGenerator::addParentForConsoleStart):
880             * runtime/CallData.cpp:
881             (JSC::call):
882             * runtime/ClassInfo.h:
883             (MethodTable):
884             * runtime/Completion.cpp:
885             (JSC::evaluate):
886             * runtime/DatePrototype.cpp:
887             (JSC::dateProtoFuncToJSON): The callee performs 'this' conversion, not
888             the caller.
889
890             * runtime/GetterSetter.cpp:
891             (JSC::callGetter):
892             (JSC::callSetter):
893             * runtime/GetterSetter.h: Added helper functions for invoking getters
894             and setters from C++ code, since this was duplicated in a bunch of
895             places.
896
897             * runtime/JSActivation.cpp:
898             (JSC::JSActivation::toThis):
899             * runtime/JSActivation.h:
900             (JSActivation):
901             * runtime/JSCJSValue.cpp:
902             (JSC::JSValue::toThisSlowCase):
903             (JSC::JSValue::putToPrimitive):
904             * runtime/JSCJSValue.h:
905             (JSValue):
906             * runtime/JSCJSValueInlines.h:
907             (JSC::JSValue::toThis):
908             * runtime/JSCell.cpp:
909             (JSC::JSCell::toThis):
910             * runtime/JSCell.h:
911             (JSCell):
912             * runtime/JSGlobalObject.cpp:
913             (JSC::JSGlobalObject::toThis):
914             * runtime/JSGlobalObject.h:
915             (JSGlobalObject): Filled out runtime support for converting 'this'
916             values as needed, according to the appropriate strictness, using
917             helper functions where getter/setter code was duplicated.
918
919             * runtime/JSGlobalObjectFunctions.cpp:
920             (JSC::globalFuncProtoGetter):
921             (JSC::globalFuncProtoSetter): Perform 'this' value conversion, since we
922             observe 'this'.
923
924             * runtime/JSNameScope.cpp:
925             (JSC::JSNameScope::toThis):
926             * runtime/JSNameScope.h:
927             (JSNameScope): Same as JSActivation.
928
929             * runtime/JSObject.cpp:
930             (JSC::JSObject::put):
931             (JSC::JSObject::setPrototypeWithCycleCheck): Bug fix. Don't peform
932             'this' value conversion in this helper function. The __proto__
933             setter does this for us, since it's the function that logically observes
934             'this' -- and we can ASSERT so. Also, the previous code used
935             "globalExec()->thisValue()", which is a read past the beginning of a
936             buffer! I don't think this ever worked on purpose.
937
938             (JSC::JSObject::toThis):
939             (JSC::JSObject::fillGetterPropertySlot):
940             * runtime/JSObject.h:
941             (JSC::JSObject::inlineGetOwnPropertySlot):
942             * runtime/JSScope.cpp:
943             (JSC::JSScope::resolveWithThis):
944             * runtime/JSString.cpp:
945             (JSC::JSString::toThis):
946             * runtime/JSString.h:
947             (JSString):
948             * runtime/PropertySlot.cpp:
949             (JSC::PropertySlot::functionGetter):
950             * runtime/PropertySlot.h:
951             (JSC):
952             (JSC::PropertySlot::setGetterSlot):
953             (JSC::PropertySlot::setCacheableGetterSlot):
954             * runtime/SparseArrayValueMap.cpp:
955             (JSC::SparseArrayEntry::get):
956             (JSC::SparseArrayEntry::put):
957             * runtime/StrictEvalActivation.cpp:
958             (JSC::StrictEvalActivation::toThis):
959             * runtime/StrictEvalActivation.h:
960             (StrictEvalActivation): Ditto.
961
962 2013-05-03  Filip Pizlo  <fpizlo@apple.com>
963
964         fourthTier: DFG::ByteCodeParser doesn't need ExecState*
965         https://bugs.webkit.org/show_bug.cgi?id=115582
966
967         Reviewed by Geoffrey Garen.
968
969         * dfg/DFGByteCodeParser.cpp:
970         (JSC::DFG::ByteCodeParser::ByteCodeParser):
971         (ByteCodeParser):
972         (JSC::DFG::parse):
973         * dfg/DFGByteCodeParser.h:
974         (DFG):
975         * dfg/DFGDriver.cpp:
976         (JSC::DFG::compile):
977
978 2013-05-02  Filip Pizlo  <fpizlo@apple.com>
979
980         fourthTier: Profiler should be thread-safe
981         https://bugs.webkit.org/show_bug.cgi?id=115445
982
983         Reviewed by Geoffrey Garen.
984         
985         Change the Profiler::Database API for Compilation creation so that we don't add
986         it to the Database until it's completely constructed. This prevents the Database
987         from seeing Compilations that are being concurrently constructed.
988         
989         Change the Profiler::Database itself to do locking for creation of Bytecodes and
990         for modifying the map. This map may be consulted by both the main thread and the
991         concurrent thread.
992
993         * dfg/DFGGraph.cpp:
994         (JSC::DFG::Graph::Graph):
995         * dfg/DFGJITCompiler.cpp:
996         (JSC::DFG::JITCompiler::link):
997         (JSC::DFG::JITCompiler::linkFunction):
998         * jit/JIT.cpp:
999         (JSC::JIT::privateCompile):
1000         * profiler/ProfilerBytecodes.h:
1001         * profiler/ProfilerDatabase.cpp:
1002         (JSC::Profiler::Database::ensureBytecodesFor):
1003         (JSC::Profiler::Database::notifyDestruction):
1004         (JSC::Profiler::Database::addCompilation):
1005         * profiler/ProfilerDatabase.h:
1006         (Database):
1007
1008 2013-05-02  Filip Pizlo  <fpizlo@apple.com>
1009
1010         fourthTier: DFG tries to ref/deref StringImpls in a ton of places
1011         https://bugs.webkit.org/show_bug.cgi?id=115300
1012
1013         Reviewed by Geoffrey Garen.
1014         
1015         Change any code transitively called from DFG compilation to use StringImpl*
1016         directly instead of String, Identifier, or PropertyName. I use the convention
1017         of passing "StringImpl* uid" instead of an Identifier or PropertyName.
1018         
1019         Switch over any code transitively called from DFG compilation to use CStrings
1020         whenever possible for all of its debug dumping.
1021         
1022         This makes it possible to compile things without hitting the ref/deref
1023         assertion in StringImpl.
1024
1025         * JavaScriptCore.xcodeproj/project.pbxproj:
1026         * bytecode/CodeBlock.cpp:
1027         (JSC::CodeBlock::inferredName):
1028         (JSC::CodeBlock::sourceCodeForTools):
1029         (JSC::CodeBlock::sourceCodeOnOneLine):
1030         (JSC::constantName):
1031         (JSC::idName):
1032         (JSC::CodeBlock::registerName):
1033         (JSC::regexpToSourceString):
1034         (JSC::regexpName):
1035         (JSC::pointerToSourceString):
1036         (JSC::CodeBlock::printUnaryOp):
1037         (JSC::CodeBlock::printBinaryOp):
1038         (JSC::CodeBlock::printConditionalJump):
1039         (JSC::CodeBlock::printGetByIdOp):
1040         (JSC::dumpStructure):
1041         (JSC::CodeBlock::printCallOp):
1042         (JSC::CodeBlock::printPutByIdOp):
1043         (JSC::CodeBlock::printStructure):
1044         (JSC::CodeBlock::printStructures):
1045         (JSC::CodeBlock::dumpBytecode):
1046         * bytecode/CodeBlock.h:
1047         (CodeBlock):
1048         * bytecode/CodeBlockHash.cpp:
1049         (JSC::CodeBlockHash::CodeBlockHash):
1050         * bytecode/CodeOrigin.cpp:
1051         (JSC::InlineCallFrame::inferredName):
1052         * bytecode/CodeOrigin.h:
1053         (InlineCallFrame):
1054         * bytecode/GetByIdStatus.cpp:
1055         (JSC::GetByIdStatus::computeFromLLInt):
1056         (JSC::GetByIdStatus::computeForChain):
1057         (JSC::GetByIdStatus::computeFor):
1058         * bytecode/GetByIdStatus.h:
1059         (JSC):
1060         (GetByIdStatus):
1061         * bytecode/PutByIdStatus.cpp:
1062         (JSC::PutByIdStatus::computeFromLLInt):
1063         (JSC::PutByIdStatus::computeFor):
1064         * bytecode/PutByIdStatus.h:
1065         (JSC):
1066         (PutByIdStatus):
1067         * bytecode/ReduceWhitespace.cpp:
1068         (JSC::reduceWhitespace):
1069         * bytecode/ReduceWhitespace.h:
1070         (JSC):
1071         * bytecode/ResolveGlobalStatus.cpp:
1072         (JSC::computeForStructure):
1073         (JSC::ResolveGlobalStatus::computeFor):
1074         * bytecode/ResolveGlobalStatus.h:
1075         (JSC):
1076         (ResolveGlobalStatus):
1077         * dfg/DFGAbstractState.cpp:
1078         (JSC::DFG::AbstractState::executeEffects):
1079         * dfg/DFGByteCodeParser.cpp:
1080         (ByteCodeParser):
1081         (JSC::DFG::ByteCodeParser::parseResolveOperations):
1082         (JSC::DFG::ByteCodeParser::parseBlock):
1083         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1084         * dfg/DFGConstantFoldingPhase.cpp:
1085         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1086         * dfg/DFGDesiredIdentifiers.cpp: Added.
1087         (DFG):
1088         (JSC::DFG::DesiredIdentifiers::DesiredIdentifiers):
1089         (JSC::DFG::DesiredIdentifiers::~DesiredIdentifiers):
1090         (JSC::DFG::DesiredIdentifiers::addLazily):
1091         (JSC::DFG::DesiredIdentifiers::reallyAdd):
1092         * dfg/DFGDesiredIdentifiers.h: Added.
1093         (DFG):
1094         (DesiredIdentifiers):
1095         (JSC::DFG::DesiredIdentifiers::numberOfIdentifiers):
1096         (JSC::DFG::DesiredIdentifiers::at):
1097         (JSC::DFG::DesiredIdentifiers::operator[]):
1098         * dfg/DFGFixupPhase.cpp:
1099         (JSC::DFG::FixupPhase::fixupNode):
1100         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
1101         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
1102         * dfg/DFGGraph.cpp:
1103         (JSC::DFG::Graph::Graph):
1104         (JSC::DFG::Graph::dump):
1105         * dfg/DFGGraph.h:
1106         (Graph):
1107         * dfg/DFGJITCompiler.cpp:
1108         (JSC::DFG::JITCompiler::link):
1109         * dfg/DFGOperations.cpp:
1110         * dfg/DFGOperations.h:
1111         * dfg/DFGRepatch.cpp:
1112         (JSC::DFG::tryBuildGetByIDList):
1113         * dfg/DFGSpeculativeJIT.h:
1114         (JSC::DFG::SpeculativeJIT::identifierUID):
1115         (JSC::DFG::SpeculativeJIT::callOperation):
1116         * dfg/DFGSpeculativeJIT32_64.cpp:
1117         (JSC::DFG::SpeculativeJIT::cachedGetById):
1118         (JSC::DFG::SpeculativeJIT::cachedPutById):
1119         (JSC::DFG::SpeculativeJIT::compile):
1120         * dfg/DFGSpeculativeJIT64.cpp:
1121         (JSC::DFG::SpeculativeJIT::cachedGetById):
1122         (JSC::DFG::SpeculativeJIT::cachedPutById):
1123         (JSC::DFG::SpeculativeJIT::compile):
1124         * parser/SourceCode.cpp: Added.
1125         (JSC):
1126         (JSC::SourceCode::toUTF8):
1127         * parser/SourceCode.h:
1128         (SourceCode):
1129         * profiler/ProfilerBytecodes.cpp:
1130         (JSC::Profiler::Bytecodes::toJS):
1131         * profiler/ProfilerBytecodes.h:
1132         (JSC::Profiler::Bytecodes::inferredName):
1133         (JSC::Profiler::Bytecodes::sourceCode):
1134         (Bytecodes):
1135         * runtime/Identifier.h:
1136         (JSC::Identifier::utf8):
1137         (JSC):
1138         * runtime/Structure.cpp:
1139         (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
1140         (JSC::Structure::addPropertyTransitionToExistingStructure):
1141         (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
1142         (JSC::Structure::getConcurrently):
1143         (JSC::Structure::prototypeChainMayInterceptStoreTo):
1144         (JSC):
1145         * runtime/Structure.h:
1146         (Structure):
1147         * runtime/StructureInlines.h:
1148         (JSC::Structure::getConcurrently):
1149
1150 2013-05-02  Filip Pizlo  <fpizlo@apple.com>
1151
1152         fourthTier: Structure transition table keys don't have to ref their StringImpl's
1153         https://bugs.webkit.org/show_bug.cgi?id=115525
1154
1155         Reviewed by Geoffrey Garen.
1156         
1157         The structure transition table basically maps string to structure. The string is
1158         always also stored, and ref'd, in the structure in Structure::m_nameInPrevious.
1159         m_nameInPrevious is never mutated, and never cleared. The string cannot die unless
1160         the structure dies. If the structure dies, then that entry in the transition map
1161         becomes a zombie anyway and we will detect this separately.
1162         
1163         So, we don't need to use RefPtr<StringImpl>. We can just use StringImpl*.
1164         
1165         This also fixes a goof where we were getting the StringImpl's hash rather than
1166         using a pointer hash. Not only is the latter faster, but it prevents my change
1167         from leading to crashes: with my change we can have zombie keys, not just zombie
1168         values. They will exist only until the next map mutation, which will clear them.
1169         Lookups will work fine because the lookup routine will reject zombies. But it
1170         does mean that the HashMap will have to deal with dangling StringImpl*'s; all it
1171         takes to make this work is to ensure that the HashMap itself never dereferences
1172         them. Using a pointer hash rather than StringImpl::existingHash() accomplishes
1173         this.
1174         
1175         This also ensures that we don't accidentally call ref() or deref() from the
1176         compilation thread, if the compilation thread inspects the transition table.
1177         
1178         And no, we wouldn't have been able to use the HashMap<RefPtr<...>, ...>
1179         specialization, because the transition table is actually
1180         HashMap<pair<RefPtr<StringImpl>, unsigned>, ...>: hence that specialization
1181         doesn't kick in. We could have written a new specialization or something, but
1182         that seemed like a lot of work given that we don't need the table to be ref'ing
1183         the strings anyways.
1184
1185         * runtime/Structure.cpp:
1186         (JSC::StructureTransitionTable::add):
1187         * runtime/StructureTransitionTable.h:
1188         (StructureTransitionTable):
1189         (Hash):
1190         (JSC::StructureTransitionTable::Hash::hash):
1191
1192 2013-05-01  Filip Pizlo  <fpizlo@apple.com>
1193
1194         fourthTier: Structure::addPropertyTransitionToExistingStructure should be thread-safe
1195         https://bugs.webkit.org/show_bug.cgi?id=115468
1196
1197         Reviewed by Geoffrey Garen.
1198         
1199         This makes the main thread modify the transition table while holding a lock. Note
1200         that the GC might modify its weak pointers without locking, but the GC will lock out
1201         the compilation thread anyway. The map will then only reshape in response to add()
1202         and set(), which happen while holding a lock.
1203         
1204         This allows the compilation thread to now query transition tables safely, provided it
1205         holds a lock when doing so.
1206         
1207         Also changed LLVM asm printer initialization to just initialize the X86 one. It makes
1208         sense for us to just initialize the asm printer(s) that we actually use; you could
1209         imagine us being linked to a system LLVM that has cross-compilation support; there is
1210         no point in the WebKit or JSC process doing work to initialize all of those targets.
1211         That part was rubber stamped by Mark Hahnenberg.
1212         
1213         * bytecode/PutByIdStatus.cpp:
1214         (JSC::PutByIdStatus::computeFor):
1215         * runtime/InitializeThreading.cpp:
1216         (JSC::initializeThreadingOnce):
1217         * runtime/Structure.cpp:
1218         (JSC::Structure::addPropertyTransitionToExistingStructureImpl):
1219         (JSC::Structure::addPropertyTransitionToExistingStructure):
1220         (JSC):
1221         (JSC::Structure::addPropertyTransitionToExistingStructureConcurrently):
1222         (JSC::Structure::addPropertyTransition):
1223         (JSC::Structure::nonPropertyTransition):
1224         * runtime/Structure.h:
1225         (Structure):
1226
1227 2013-04-30  Filip Pizlo  <fpizlo@apple.com>
1228
1229         fourthTier: Structure::getConcurrently() may be called from for uncacheable dictionaries, and this is safe
1230         https://bugs.webkit.org/show_bug.cgi?id=115464
1231
1232         Reviewed by Oliver Hunt and Geoffrey Garen.
1233         
1234         This can happen for example transitively from JSObject::put(). getCurrently() does
1235         work for uncacheable dictionaries; it just has the obvious race that right after it
1236         returns, the result it returned may no longer be right. This isn't an issue if it was
1237         called on the main thread, and may not be an issue in some other situations.
1238         
1239         So, we should just remove the assertion, since the only thing it buys us is crashes.
1240
1241         * runtime/Structure.cpp:
1242         (JSC::Structure::getConcurrently):
1243
1244 2013-04-30  Filip Pizlo  <fpizlo@apple.com>
1245
1246         fourthTier: Don't link gtest into JavaScriptCore
1247
1248         Rubber stamped by Mark Rowe.
1249
1250         * Configurations/JavaScriptCore.xcconfig:
1251
1252 2013-04-29  Filip Pizlo  <fpizlo@apple.com>
1253
1254         fourthTier: String::utf8() should also be available as StringImpl::utf8() so that you don't have to ref() a StringImpl just to get its utf8()
1255         https://bugs.webkit.org/show_bug.cgi?id=115393
1256
1257         Reviewed by Geoffrey Garen.
1258
1259         * runtime/JSGlobalObjectFunctions.cpp:
1260         (JSC::encode):
1261
1262 2013-07-16  Oliver Hunt <oliver@apple.com>
1263
1264         Merge dfgFourthTier r149301
1265
1266     2013-04-28  Filip Pizlo  <fpizlo@apple.com>
1267
1268         fourthTier: ASSERT that commonly used not-thread-safe methods in the runtime are not being called during compilation
1269         https://bugs.webkit.org/show_bug.cgi?id=115297
1270
1271         Reviewed by Geoffrey Garen.
1272         
1273         Put in assertions that we're not doing bad things in compilation threads. Also
1274         factored compilation into compile+link so that even though we don't yet have
1275         concurrent compilation, we can be explicit about which parts of DFG work are
1276         meant to be concurrent, and which aren't.
1277         
1278         Also fix a handful of bugs found by these assertions.
1279
1280         * JavaScriptCore.xcodeproj/project.pbxproj:
1281         * bytecode/ResolveGlobalStatus.cpp:
1282         (JSC::computeForStructure):
1283         * bytecode/Watchpoint.cpp:
1284         (JSC::WatchpointSet::add):
1285         (JSC::InlineWatchpointSet::inflateSlow):
1286         * dfg/DFGDriver.cpp:
1287         (JSC::DFG::compile):
1288         * dfg/DFGJITCompiler.cpp:
1289         (JSC::DFG::JITCompiler::~JITCompiler):
1290         (DFG):
1291         (JSC::DFG::JITCompiler::compileBody):
1292         (JSC::DFG::JITCompiler::compile):
1293         (JSC::DFG::JITCompiler::link):
1294         (JSC::DFG::JITCompiler::compileFunction):
1295         (JSC::DFG::JITCompiler::linkFunction):
1296         * dfg/DFGJITCompiler.h:
1297         (JITCompiler):
1298         * ftl/FTLCompile.cpp:
1299         (JSC::FTL::compile):
1300         * ftl/FTLCompile.h:
1301         (FTL):
1302         * ftl/FTLLink.cpp: Added.
1303         (FTL):
1304         (JSC::FTL::compileEntry):
1305         (JSC::FTL::link):
1306         * ftl/FTLLink.h: Added.
1307         (FTL):
1308         * ftl/FTLState.cpp:
1309         (JSC::FTL::State::State):
1310         * ftl/FTLState.h:
1311         (FTL):
1312         (State):
1313         * runtime/Structure.cpp:
1314         (JSC::Structure::get):
1315         (JSC::Structure::prototypeChainMayInterceptStoreTo):
1316         * runtime/Structure.h:
1317         (JSC::Structure::materializePropertyMapIfNecessary):
1318         * runtime/StructureInlines.h:
1319         (JSC::Structure::get):
1320
1321 2013-04-27  Filip Pizlo  <fpizlo@apple.com>
1322
1323         FTL should support double variables
1324         https://bugs.webkit.org/show_bug.cgi?id=113624
1325
1326         Reviewed by Geoffrey Garen.
1327         
1328         Made all of the operations that the FTL already supports, also support doubles.
1329         OSR exit already basically had everything it needed, so no changes there. This
1330         mostly just glues together bits of DFG IR to LLVM IR, in a straight-forward way.
1331
1332         * ftl/FTLAbbreviations.h:
1333         (FTL):
1334         (JSC::FTL::doubleType):
1335         (JSC::FTL::constReal):
1336         (JSC::FTL::buildPhi):
1337         (JSC::FTL::addIncoming):
1338         (JSC::FTL::buildFAdd):
1339         (JSC::FTL::buildFSub):
1340         (JSC::FTL::buildFMul):
1341         (JSC::FTL::buildFNeg):
1342         (JSC::FTL::buildSIToFP):
1343         (JSC::FTL::buildUIToFP):
1344         (JSC::FTL::buildBitCast):
1345         (JSC::FTL::buildFCmp):
1346         * ftl/FTLCapabilities.cpp:
1347         (JSC::FTL::canCompile):
1348         * ftl/FTLCommonValues.cpp:
1349         (JSC::FTL::CommonValues::CommonValues):
1350         * ftl/FTLCommonValues.h:
1351         (CommonValues):
1352         * ftl/FTLLowerDFGToLLVM.cpp:
1353         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
1354         (JSC::FTL::LowerDFGToLLVM::lower):
1355         (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
1356         (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
1357         (JSC::FTL::LowerDFGToLLVM::compileAdd):
1358         (JSC::FTL::LowerDFGToLLVM::compileArithSub):
1359         (JSC::FTL::LowerDFGToLLVM::compileArithMul):
1360         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
1361         (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
1362         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
1363         (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
1364         (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
1365         (JSC::FTL::LowerDFGToLLVM::lowDouble):
1366         (LowerDFGToLLVM):
1367         (JSC::FTL::LowerDFGToLLVM::lowJSValue):
1368         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
1369         (JSC::FTL::LowerDFGToLLVM::unboxDouble):
1370         (JSC::FTL::LowerDFGToLLVM::boxDouble):
1371         (JSC::FTL::LowerDFGToLLVM::speculate):
1372         (JSC::FTL::LowerDFGToLLVM::speculateNumber):
1373         (JSC::FTL::LowerDFGToLLVM::speculateRealNumber):
1374         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
1375         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
1376         * ftl/FTLOutput.h:
1377         (JSC::FTL::Output::constDouble):
1378         (Output):
1379         (JSC::FTL::Output::phi):
1380         (JSC::FTL::Output::doubleAdd):
1381         (JSC::FTL::Output::doubleSub):
1382         (JSC::FTL::Output::doubleMul):
1383         (JSC::FTL::Output::doubleNeg):
1384         (JSC::FTL::Output::intToFP):
1385         (JSC::FTL::Output::intToDouble):
1386         (JSC::FTL::Output::unsignedToFP):
1387         (JSC::FTL::Output::unsignedToDouble):
1388         (JSC::FTL::Output::bitCast):
1389         (JSC::FTL::Output::loadDouble):
1390         (JSC::FTL::Output::storeDouble):
1391         (JSC::FTL::Output::doubleEqual):
1392         (JSC::FTL::Output::doubleNotEqualOrUnordered):
1393         (JSC::FTL::Output::doubleLessThan):
1394         (JSC::FTL::Output::doubleLessThanOrEqual):
1395         (JSC::FTL::Output::doubleGreaterThan):
1396         (JSC::FTL::Output::doubleGreaterThanOrEqual):
1397         (JSC::FTL::Output::doubleEqualOrUnordered):
1398         (JSC::FTL::Output::doubleNotEqual):
1399         (JSC::FTL::Output::doubleLessThanOrUnordered):
1400         (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
1401         (JSC::FTL::Output::doubleGreaterThanOrUnordered):
1402         (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
1403         (JSC::FTL::Output::testIsZero64):
1404
1405 2013-04-27  Filip Pizlo  <fpizlo@apple.com>
1406
1407         fourthTier: SymbolTable should be thread-safe
1408         https://bugs.webkit.org/show_bug.cgi?id=115301
1409
1410         Reviewed by Geoffrey Garen.
1411         
1412         Makes SymbolTable thread-safe. Relies on SymbolTableEntry already being immutable,
1413         other than the WatchpointSet; but the WatchpointSet already has a righteous
1414         concurrency protocol. So, this patch just protects the SymbolTable's HashMap.
1415
1416         * bytecode/CodeBlock.cpp:
1417         (JSC::CodeBlock::nameForRegister):
1418         * bytecompiler/BytecodeGenerator.cpp:
1419         (JSC::BytecodeGenerator::addVar):
1420         * runtime/Executable.cpp:
1421         (JSC::ProgramExecutable::addGlobalVar):
1422         * runtime/JSActivation.cpp:
1423         (JSC::JSActivation::getOwnNonIndexPropertyNames):
1424         (JSC::JSActivation::symbolTablePutWithAttributes):
1425         * runtime/JSSymbolTableObject.cpp:
1426         (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
1427         * runtime/JSSymbolTableObject.h:
1428         (JSC::symbolTableGet):
1429         (JSC::symbolTablePut):
1430         (JSC::symbolTablePutWithAttributes):
1431         * runtime/SymbolTable.cpp:
1432         (JSC::SymbolTable::SymbolTable):
1433         (JSC::SymbolTable::~SymbolTable):
1434         * runtime/SymbolTable.h:
1435         (JSC::SymbolTable::find):
1436         (JSC::SymbolTable::get):
1437         (JSC::SymbolTable::inlineGet):
1438         (JSC::SymbolTable::begin):
1439         (JSC::SymbolTable::end):
1440         (JSC::SymbolTable::size):
1441         (JSC::SymbolTable::add):
1442         (JSC::SymbolTable::set):
1443         (JSC::SymbolTable::contains):
1444
1445 2013-04-26  Filip Pizlo  <fpizlo@apple.com>
1446
1447         fourthTier: WatchpointSet should make racy uses easier to reason about
1448         https://bugs.webkit.org/show_bug.cgi?id=115299
1449
1450         Reviewed by Anders Carlsson.
1451         
1452         The compiler often does things like:
1453
1454         1c) Observe something that would imply that a WatchpointSet ought to be invalid
1455
1456         2c) Check that it is invalid
1457
1458         The main thread often does things like:
1459
1460         1m) Fire the watchpoint set
1461
1462         2m) Do some other thing that would cause the compiler to assume that the WatchpointSet
1463         ought to be invalid
1464
1465         An example is structure transitions, where (1c) is the compiler noticing that a
1466         put_by_id inline cache is in a transition state, with the source structure being S;
1467         (2c) is the compiler asserting that S's watchpoint set is invalid; (1m) is the main
1468         thread firing S's watchpoint set before it does the first transition away from S; and
1469         (2m) is the main thread caching the put_by_id transition away from S.
1470
1471         This is totally fine, except that (1c) and (2c), and (1m) and (2m) could be reordered.
1472         Probably, in most cases, this ought to do enough things that the main thread probably
1473         already has some fencing. But the compiler thread definitely doesn't have fencing. In
1474         any case, we should play it safe and just have additional fencing in all of the
1475         relevant places.
1476
1477         We already have some idioms to put load-load and store-store fences in the right
1478         places. But this change just makes WatchpointSet take care of this for us, thus
1479         reducing the chances of us getting this wrong.
1480
1481         * bytecode/Watchpoint.cpp:
1482         (JSC::WatchpointSet::notifyWriteSlow):
1483         * bytecode/Watchpoint.h:
1484         (WatchpointSet):
1485         (JSC::WatchpointSet::isStillValid):
1486         (JSC::WatchpointSet::hasBeenInvalidated):
1487         (JSC::InlineWatchpointSet::hasBeenInvalidated):
1488         (JSC::InlineWatchpointSet::notifyWrite):
1489         * dfg/DFGByteCodeParser.cpp:
1490         (JSC::DFG::ByteCodeParser::parseBlock):
1491         * dfg/DFGDesiredWatchpoints.h:
1492         (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
1493
1494 2013-07-16  Oliver Hunt <oliver@apple.com>
1495
1496         Merge dfgFourthTier r149233
1497
1498     2013-04-26  Filip Pizlo  <fpizlo@apple.com>
1499
1500         fourthTier: CFA should defend against results seeming inconsistent due to a watchpoint firing during compilation
1501         https://bugs.webkit.org/show_bug.cgi?id=115083
1502
1503         Reviewed by Geoffrey Garen.
1504         
1505         This ruggedizes our racyness with respect to watchpoints. We want to be able to assert,
1506         in some places, that a watchpoint-based optimization has only occurred if the
1507         watchpoint set was still valid. But currently we *can* soundly do watchpoint-based
1508         optimizations even for invalid watchpoints, so long as we recorded in the IR that we
1509         had done so; this will then lead to the code being insta-jettisoned after compilation
1510         completes. Obviously, we don't want this to happen often - but we do want to allow it
1511         precisely in the case of watchpoint races.
1512         
1513         This adds the ability to assert that we hadn't over-watchpointed ourselves, with and
1514         exemption for races.
1515
1516         * dfg/DFGAbstractState.cpp:
1517         (JSC::DFG::AbstractState::executeEffects):
1518         * dfg/DFGAbstractValue.cpp:
1519         (JSC::DFG::AbstractValue::setFuturePossibleStructure):
1520         (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
1521         * dfg/DFGByteCodeParser.cpp:
1522         (JSC::DFG::ByteCodeParser::addStructureTransitionCheck):
1523         (JSC::DFG::ByteCodeParser::parseResolveOperations):
1524         (JSC::DFG::ByteCodeParser::parseBlock):
1525         * dfg/DFGConstantFoldingPhase.cpp:
1526         (JSC::DFG::ConstantFoldingPhase::addStructureTransitionCheck):
1527         * dfg/DFGDesiredWatchpoints.h:
1528         (GenericDesiredWatchpoints):
1529         (JSC::DFG::GenericDesiredWatchpoints::isStillValid):
1530         (JSC::DFG::GenericDesiredWatchpoints::shouldAssumeMixedState):
1531         (JSC::DFG::GenericDesiredWatchpoints::isValidOrMixed):
1532         (JSC::DFG::DesiredWatchpoints::isStillValid):
1533         (JSC::DFG::DesiredWatchpoints::shouldAssumeMixedState):
1534         (JSC::DFG::DesiredWatchpoints::isValidOrMixed):
1535         (DesiredWatchpoints):
1536         * dfg/DFGFixupPhase.cpp:
1537         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
1538         * dfg/DFGGraph.h:
1539         (JSC::DFG::Graph::masqueradesAsUndefinedWatchpointIsStillValid):
1540         (Graph):
1541         * dfg/DFGJITCompiler.cpp:
1542         (JSC::DFG::JITCompiler::link):
1543         (JSC::DFG::JITCompiler::compile):
1544         (JSC::DFG::JITCompiler::compileFunction):
1545         * dfg/DFGJITCompiler.h:
1546         (JSC::DFG::JITCompiler::addLazily):
1547         (JITCompiler):
1548         * dfg/DFGSpeculativeJIT.cpp:
1549         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
1550         * dfg/DFGSpeculativeJIT.h:
1551         (SpeculativeJIT):
1552         (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
1553         (JSC::DFG::SpeculativeJIT::speculationWatchpointForMasqueradesAsUndefined):
1554         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
1555         * dfg/DFGSpeculativeJIT32_64.cpp:
1556         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
1557         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
1558         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1559         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1560         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1561         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1562         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1563         (JSC::DFG::SpeculativeJIT::compile):
1564         * dfg/DFGSpeculativeJIT64.cpp:
1565         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
1566         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
1567         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1568         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1569         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1570         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1571         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1572         (JSC::DFG::SpeculativeJIT::compile):
1573         * ftl/FTLCompile.cpp:
1574         (JSC::FTL::compile):
1575         * ftl/FTLState.h:
1576         (State):
1577
1578 2013-04-23  Filip Pizlo  <fpizlo@apple.com>
1579
1580         fourthTier: AbstractValue methods that deal with watchpoints should have access to Graph, so that in debug mode, Graph can track the history of watchpoint states and detect races
1581         https://bugs.webkit.org/show_bug.cgi?id=115084
1582
1583         Reviewed by Geoffrey Garen.
1584         
1585         The idea is that as part of https://bugs.webkit.org/show_bug.cgi?id=115083, I'll have
1586         Graph record the initial state of a watchpoint at the time that we decide to take
1587         advantage of it; then I will use this to disable any watchpoint-related assertions
1588         in debug mode. Note that this "watchpoint cache" will only be maintained in debug
1589         mode, so there will be no release performance implications. But to do this, I need to
1590         ensure that all of the places that reason about watchpoints have access to Graph.
1591         For example, I'll want AbstractValue::setFuturePossibleStructure to record the state
1592         of the watchpoint in Graph so that subsequent assertions can check if the watchpoint's
1593         state had changed since that decision was made.
1594
1595         * JavaScriptCore.xcodeproj/project.pbxproj:
1596         * dfg/DFGAbstractState.cpp:
1597         (JSC::DFG::AbstractState::initialize):
1598         (JSC::DFG::AbstractState::executeEffects):
1599         (JSC::DFG::AbstractState::mergeStateAtTail):
1600         * dfg/DFGAbstractState.h:
1601         (JSC::DFG::AbstractState::trySetConstant):
1602         * dfg/DFGAbstractValue.cpp: Added.
1603         (DFG):
1604         (JSC::DFG::AbstractValue::setMostSpecific):
1605         (JSC::DFG::AbstractValue::set):
1606         (JSC::DFG::AbstractValue::filter):
1607         (JSC::DFG::AbstractValue::setFuturePossibleStructure):
1608         (JSC::DFG::AbstractValue::filterFuturePossibleStructure):
1609         (JSC::DFG::AbstractValue::dump):
1610         * dfg/DFGAbstractValue.h:
1611         (DFG):
1612         (AbstractValue):
1613         (JSC::DFG::AbstractValue::setType):
1614         (JSC::DFG::AbstractValue::filterByValue):
1615
1616 2013-07-16  Oliver Hunt <oliver@apple.com>
1617
1618         Merge dfgFourthTier r148936
1619
1620     2013-04-22  Filip Pizlo  <fpizlo@apple.com>
1621
1622         fourthTier: Create an equivalent of Structure::get() that can work from a compilation thread
1623         https://bugs.webkit.org/show_bug.cgi?id=114987
1624
1625         Reviewed by Geoffrey Garen.
1626         
1627         This completes the work started by r148570. That patch made it possible to do
1628         Structure::get() without modifying Structure. This patch takes this further, and
1629         makes this thread-safe (for non-uncacheable-dictionaries) via
1630         Structure::getConcurrently(). This method not only doesn't modify Structure, but
1631         also ensures that any concurrent attempts to add to, remove from, or steal the
1632         table from that structure doesn't mess up the result of the call. The call may
1633         return invalidOffset even if a property is *just* about to be added, but it will
1634         never do the reverse: if it returns a property then you can be sure that the
1635         structure really does have that property and always will have it.
1636
1637         * bytecode/GetByIdStatus.cpp:
1638         (JSC::GetByIdStatus::computeFromLLInt):
1639         (JSC::GetByIdStatus::computeForChain):
1640         (JSC::GetByIdStatus::computeFor):
1641         * bytecode/PutByIdStatus.cpp:
1642         (JSC::PutByIdStatus::computeFromLLInt):
1643         (JSC::PutByIdStatus::computeFor):
1644         * dfg/DFGFixupPhase.cpp:
1645         (JSC::DFG::FixupPhase::isStringPrototypeMethodSane):
1646         * runtime/PropertyMapHashTable.h:
1647         (PropertyTable):
1648         (JSC::PropertyTable::findConcurrently):
1649         (JSC):
1650         (JSC::PropertyTable::add):
1651         (JSC::PropertyTable::remove):
1652         (JSC::PropertyTable::reinsert):
1653         (JSC::PropertyTable::rehash):
1654         * runtime/PropertyTable.cpp:
1655         (JSC::PropertyTable::PropertyTable):
1656         * runtime/Structure.cpp:
1657         (JSC::Structure::findStructuresAndMapForMaterialization):
1658         (JSC::Structure::getConcurrently):
1659         * runtime/Structure.h:
1660         (Structure):
1661         * runtime/StructureInlines.h:
1662         (JSC::Structure::getConcurrently):
1663
1664 2013-07-16  Oliver Hunt <oliver@apple.com>
1665
1666         Merge dfgFourthTier r148850
1667
1668     2013-04-21  Filip Pizlo  <fpizlo@apple.com>
1669
1670         fourthTier: WebKit's build system should relink JavaScriptCore if LLVM's libraries changed but its headers didn't
1671         https://bugs.webkit.org/show_bug.cgi?id=114926
1672
1673         Reviewed by Geoffrey Garen.
1674         
1675         Use a phony file that includes a phony header to force JavaScriptCore to be relinked
1676         if necessary. The external LLVM-importing scripts will touch the header if the libraries
1677         are known to have changed.
1678
1679         * JavaScriptCore.xcodeproj/project.pbxproj:
1680         * ftl/WebKitLLVMLibraryAnchor.cpp: Added.
1681
1682 2013-07-16  Oliver Hunt <oliver@apple.com>
1683
1684         Merge dfgFourthTier r148836
1685
1686     2013-04-21  Filip Pizlo  <fpizlo@apple.com>
1687
1688         fourthTier: It should be possible to query WatchpointSets, and add Watchpoints, even if the compiler is running in another thread
1689         https://bugs.webkit.org/show_bug.cgi?id=114909
1690
1691         Reviewed by Oliver Hunt.
1692         
1693         The idea here is that a concurrent compiler will use watchpoint sets as follows:
1694         
1695         During concurrent compilation: It will create Watchpoints, and query WatchpointSets only
1696         for the purpose of profiling. That is, it will use decide whether it is profitable to
1697         compile the code "as if" the watchpoint sets are valid.
1698         
1699         During synchronous linking: By "linking" I don't necessarily mean the LinkBuffer stuff,
1700         but just the very bitter end of compilation where we make the JIT code callable. This
1701         can happen after LinkBuffer stuff. Anyway, this will have to happen synchronously, and
1702         at that point we can (a) check that all WatchpointSets that we assumed were valid are
1703         still valid and (b) if they are then we add the watchpoints to those sets. If any of the
1704         sets are invalid, we give up on this compilation and try again later.
1705         
1706         The querying of WatchpointSets is engineered to say that the set is still valid if it
1707         is so *right now*, but this is done in a racy way and so it may say so spuriously: we
1708         may, with hopefully low probability, have a set that says it is valid even though it was
1709         just invalidated. The goal is only to ensure that (i) a set never claims to be invalid
1710         if it is actually valid, (ii) a set doesn't claim to be valid if it was invalidated
1711         before compilation even began, and (iii) querying the validity of a set doesn't cause us
1712         to crash.
1713
1714         * JavaScriptCore.xcodeproj/project.pbxproj:
1715         * bytecode/Watchpoint.cpp:
1716         (JSC::InlineWatchpointSet::inflateSlow):
1717         * bytecode/Watchpoint.h:
1718         (WatchpointSet):
1719         (InlineWatchpointSet):
1720         (JSC::InlineWatchpointSet::hasBeenInvalidated):
1721         (JSC::InlineWatchpointSet::isThin):
1722         (JSC::InlineWatchpointSet::isFat):
1723         (JSC::InlineWatchpointSet::fat):
1724         * dfg/DFGDesiredWatchpoints.cpp: Added.
1725         (DFG):
1726         (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
1727         (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
1728         (JSC::DFG::DesiredWatchpoints::addLazily):
1729         (JSC::DFG::DesiredWatchpoints::reallyAdd):
1730         (JSC::DFG::DesiredWatchpoints::areStillValid):
1731         * dfg/DFGDesiredWatchpoints.h: Added.
1732         (DFG):
1733         (JSC::DFG::WatchpointForGenericWatchpointSet::WatchpointForGenericWatchpointSet):
1734         (WatchpointForGenericWatchpointSet):
1735         (GenericDesiredWatchpoints):
1736         (JSC::DFG::GenericDesiredWatchpoints::GenericDesiredWatchpoints):
1737         (JSC::DFG::GenericDesiredWatchpoints::addLazily):
1738         (JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
1739         (JSC::DFG::GenericDesiredWatchpoints::areStillValid):
1740         (DesiredWatchpoints):
1741         * dfg/DFGDriver.cpp:
1742         (JSC::DFG::compile):
1743         * dfg/DFGJITCompiler.cpp:
1744         (JSC::DFG::JITCompiler::link):
1745         (JSC::DFG::JITCompiler::compile):
1746         (JSC::DFG::JITCompiler::compileFunction):
1747         * dfg/DFGJITCompiler.h:
1748         (JSC::DFG::JITCompiler::addLazily):
1749         (JITCompiler):
1750         * dfg/DFGSpeculativeJIT.cpp:
1751         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
1752         * dfg/DFGSpeculativeJIT32_64.cpp:
1753         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
1754         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
1755         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1756         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1757         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1758         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1759         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1760         (JSC::DFG::SpeculativeJIT::compile):
1761         * dfg/DFGSpeculativeJIT64.cpp:
1762         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
1763         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
1764         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
1765         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
1766         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
1767         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
1768         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
1769         (JSC::DFG::SpeculativeJIT::compile):
1770         * ftl/FTLCompile.cpp:
1771         (JSC::FTL::compile):
1772         * ftl/FTLCompile.h:
1773         (FTL):
1774         * ftl/FTLState.h:
1775         (State):
1776         * runtime/JSFunction.h:
1777         (JSFunction):
1778         (JSC::JSFunction::allocationProfileWatchpointSet):
1779         * runtime/Structure.h:
1780         (Structure):
1781         (JSC::Structure::transitionWatchpointSet):
1782
1783 2013-07-16  Oliver Hunt <oliver@apple.com>
1784
1785         Merge dfgFourthTier r148804
1786
1787     2013-04-20  Filip Pizlo  <fpizlo@apple.com>
1788
1789         fourthTier: value profiles and array profiles should be thread-safe enough to be accessible in a concurrent compilation thread
1790         https://bugs.webkit.org/show_bug.cgi?id=114906
1791
1792         Reviewed by Oliver Hunt.
1793         
1794         This introduces thread safety to value profiles, array profiles, and
1795         array allocation profiles.
1796         
1797         We already have three separate operations that happen on profiles:
1798         (1) writing, which the JIT, LLInt, and OSR exit do; (2) updating,
1799         which happens during GC, from OSR entry slow-paths, and in the DFG;
1800         and (3) reading, which happens in the DFG. For example, the JIT/LLInt
1801         and OSR exit write to ValueProfile::m_buckets, which gets synthesized
1802         into ValueProfile::m_prediction (and other fields) during update, and
1803         the latter gets read by the DFG. Note that (2) must also happen in
1804         the DFG since only the DFG knows which code blocks it will inline,
1805         and those blocks' profiles may not have otherwise been updated via
1806         any other mechanism.
1807         
1808         I refer to these three operations as writing, updating, and reading.
1809         
1810         Consequently, both profile updating and profile reading may happen
1811         asynchronously, if the JIT is asynchronous.
1812         
1813         The locking protocol for profiles works as follows:
1814         
1815         - Writing does not require locking, but is only allowed on the main
1816           thread. We require that these fields can be stored atomically by
1817           the profiling code, even without locks. For value profiles, this
1818           only works on 64-bit platforms, currently. For array profiles,
1819           which consist of multiple separate fields, this means that an
1820           asynchronous update of the profile may see slight inconsistencies
1821           (like a structure that doesn't quite match the array modes bits),
1822           but these should be harmless: at worst, the DFG will specialize
1823           too much and we'll have OSR exits.
1824         
1825         - Updating a value profile requires holding a lock, but must assume
1826           that the fields written by the profiling code in JIT/LLInt may
1827           be written to without locking.
1828         
1829         - Reading a value profile requires holding a lock.
1830         
1831         The one major exception to these rules is the ArrayAllocationProfile,
1832         which requires no locking. We do this because it's used so often and
1833         in places where we don't necessarily have access to the owning
1834         CodeBlock, so if we did want it to be locked it would have to have
1835         its own lock. Also, I believe that it is sound to just make this
1836         profile racy and not worry about locking at all. All that was needed
1837         were some changes to ensure that we explicitly read some raced-over
1838         fields only once.
1839
1840         Two additional interesting things in this change:
1841         
1842         - To make it easy to see which profile methods require locking, they
1843           take a const CodeBlockLocker& as an argument. I saw this idiom for
1844           identifying which methods require which locks to be held being used
1845           in LLVM, and I quite like it.
1846         
1847         - Lazy operand value profiles, which are created lazily and at any
1848           time, require the CodeBlockLock to be held when they are being
1849           created. Writes to them are lockless and main-thread-only, but as
1850           with other profiles, updates and reads require locking.
1851
1852         * JavaScriptCore.xcodeproj/project.pbxproj:
1853         * bytecode/ArrayAllocationProfile.cpp:
1854         (JSC::ArrayAllocationProfile::updateIndexingType):
1855         * bytecode/ArrayAllocationProfile.h:
1856         (JSC::ArrayAllocationProfile::selectIndexingType):
1857         * bytecode/ArrayProfile.cpp:
1858         (JSC::ArrayProfile::computeUpdatedPrediction):
1859         (JSC::ArrayProfile::briefDescription):
1860         * bytecode/ArrayProfile.h:
1861         (ArrayProfile):
1862         (JSC::ArrayProfile::expectedStructure):
1863         (JSC::ArrayProfile::structureIsPolymorphic):
1864         (JSC::ArrayProfile::hasDefiniteStructure):
1865         (JSC::ArrayProfile::observedArrayModes):
1866         (JSC::ArrayProfile::mayInterceptIndexedAccesses):
1867         (JSC::ArrayProfile::mayStoreToHole):
1868         (JSC::ArrayProfile::outOfBounds):
1869         (JSC::ArrayProfile::usesOriginalArrayStructures):
1870         * bytecode/CallLinkStatus.cpp:
1871         (JSC::CallLinkStatus::computeFor):
1872         * bytecode/CodeBlock.cpp:
1873         (JSC::CodeBlock::dumpValueProfiling):
1874         (JSC::CodeBlock::dumpArrayProfiling):
1875         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
1876         (JSC::CodeBlock::updateAllArrayPredictions):
1877         * bytecode/CodeBlock.h:
1878         (JSC::CodeBlock::valueProfilePredictionForBytecodeOffset):
1879         (JSC::CodeBlock::updateAllPredictionsAndCheckIfShouldOptimizeNow):
1880         (CodeBlock):
1881         * bytecode/CodeBlockLock.h: Added.
1882         (JSC):
1883         * bytecode/GetByIdStatus.cpp:
1884         (JSC::GetByIdStatus::computeFor):
1885         * bytecode/LazyOperandValueProfile.cpp:
1886         (JSC::CompressedLazyOperandValueProfileHolder::computeUpdatedPredictions):
1887         (JSC::CompressedLazyOperandValueProfileHolder::add):
1888         (JSC::LazyOperandValueProfileParser::LazyOperandValueProfileParser):
1889         (JSC::LazyOperandValueProfileParser::~LazyOperandValueProfileParser):
1890         (JSC):
1891         (JSC::LazyOperandValueProfileParser::initialize):
1892         (JSC::LazyOperandValueProfileParser::prediction):
1893         * bytecode/LazyOperandValueProfile.h:
1894         (CompressedLazyOperandValueProfileHolder):
1895         (LazyOperandValueProfileParser):
1896         * bytecode/MethodOfGettingAValueProfile.cpp:
1897         (JSC::MethodOfGettingAValueProfile::getSpecFailBucket):
1898         * bytecode/PutByIdStatus.cpp:
1899         (JSC::PutByIdStatus::computeFor):
1900         * bytecode/ResolveGlobalStatus.cpp:
1901         (JSC::ResolveGlobalStatus::computeFor):
1902         * bytecode/ValueProfile.h:
1903         (JSC::ValueProfileBase::briefDescription):
1904         (ValueProfileBase):
1905         (JSC::ValueProfileBase::computeUpdatedPrediction):
1906         * dfg/DFGArrayMode.cpp:
1907         (JSC::DFG::ArrayMode::fromObserved):
1908         * dfg/DFGArrayMode.h:
1909         (ArrayMode):
1910         (JSC::DFG::ArrayMode::withProfile):
1911         * dfg/DFGByteCodeParser.cpp:
1912         (JSC::DFG::ByteCodeParser::injectLazyOperandSpeculation):
1913         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
1914         (JSC::DFG::ByteCodeParser::getArrayMode):
1915         (JSC::DFG::ByteCodeParser::getArrayModeAndEmitChecks):
1916         (JSC::DFG::ByteCodeParser::parseResolveOperations):
1917         (JSC::DFG::ByteCodeParser::parseBlock):
1918         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1919         * dfg/DFGFixupPhase.cpp:
1920         (JSC::DFG::FixupPhase::fixupNode):
1921         * dfg/DFGOSRExitPreparation.cpp:
1922         (JSC::DFG::prepareCodeOriginForOSRExit):
1923         * dfg/DFGPredictionInjectionPhase.cpp:
1924         (JSC::DFG::PredictionInjectionPhase::run):
1925         * jit/JITInlines.h:
1926         (JSC::JIT::chooseArrayMode):
1927         * jit/JITStubs.cpp:
1928         (JSC::tryCachePutByID):
1929         (JSC::tryCacheGetByID):
1930         (JSC::DEFINE_STUB_FUNCTION):
1931         (JSC::lazyLinkFor):
1932         * llint/LLIntSlowPaths.cpp:
1933         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1934         (JSC::LLInt::setUpCall):
1935         * profiler/ProfilerBytecodeSequence.cpp:
1936         (JSC::Profiler::BytecodeSequence::BytecodeSequence):
1937         * runtime/JSScope.cpp:
1938         (JSC::JSScope::resolveContainingScopeInternal):
1939         (JSC::JSScope::resolvePut):
1940
1941 2013-04-17  Filip Pizlo  <fpizlo@apple.com>
1942
1943         fourthTier: all inline caches should thread-safe enough to allow a concurrent compilation thread to read them safely
1944         https://bugs.webkit.org/show_bug.cgi?id=114762
1945
1946         Reviewed by Mark Hahnenberg.
1947         
1948         For most inline caches this is easy: the inline cache has a clean temporal
1949         separation between doing the requested action (which may take an unbounded
1950         amount of time, may recurse, and may do arbitrary things) and recording the
1951         relevant information in the cache. So, we just put locks around the
1952         recording bit. That part is always O(1) and does not recurse. The lock we
1953         use is per-CodeBlock to achieve a good balance between locking granularity
1954         and low space overhead. So a concurrent compilation thread will only block
1955         if an inline cache ping-pongs in the code block being compiled (or inlined)
1956         and never when other inline caches do things.
1957         
1958         For resolve operations, it's a bit tricky. The global resolve bit works
1959         like any other IC in that it has the clean temporal separation. But the
1960         operations vector itself doesn't have this separation, since we will be
1961         filling it in tandem with actions that may take a long time. This patch
1962         gets around this by having a m_ready bit in the ResolveOperations and
1963         PutToBaseOperation. This is set while holding the CodeBlock's lock. If the
1964         DFG observes the m_ready bit not set (while holding the lock) then it
1965         conservatively assumes that the resolve hasn't happened yet and just
1966         plants a ForceOSRExit.
1967
1968         * bytecode/CallLinkStatus.cpp:
1969         (JSC::CallLinkStatus::computeFor):
1970         * bytecode/CodeBlock.h:
1971         (CodeBlock):
1972         * bytecode/GetByIdStatus.cpp:
1973         (JSC::GetByIdStatus::computeFor):
1974         * bytecode/PutByIdStatus.cpp:
1975         (JSC::PutByIdStatus::computeFor):
1976         * bytecode/ResolveGlobalStatus.cpp:
1977         (JSC::ResolveGlobalStatus::computeFor):
1978         * bytecode/ResolveOperation.h:
1979         (JSC::ResolveOperations::ResolveOperations):
1980         (ResolveOperations):
1981         (JSC::PutToBaseOperation::PutToBaseOperation):
1982         * dfg/DFGByteCodeParser.cpp:
1983         (JSC::DFG::ByteCodeParser::parseResolveOperations):
1984         (JSC::DFG::ByteCodeParser::parseBlock):
1985         * jit/JITStubs.cpp:
1986         (JSC::tryCachePutByID):
1987         (JSC::tryCacheGetByID):
1988         (JSC::DEFINE_STUB_FUNCTION):
1989         (JSC::lazyLinkFor):
1990         * llint/LLIntSlowPaths.cpp:
1991         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1992         (JSC::LLInt::setUpCall):
1993         * runtime/JSScope.cpp:
1994         (JSC::JSScope::resolveContainingScopeInternal):
1995         (JSC::JSScope::resolveContainingScope):
1996         (JSC::JSScope::resolvePut):
1997
1998 2013-04-16  Filip Pizlo  <fpizlo@apple.com>
1999
2000         fourthTier: DFG should be able to query Structure without modifying it
2001         https://bugs.webkit.org/show_bug.cgi?id=114708
2002
2003         Reviewed by Oliver Hunt.
2004         
2005         This is work towards allowing the DFG, and FTL, to run on a separate thread.
2006         The idea is that the most evil thing that the DFG does that has thread-safety
2007         issues is fiddling with Structures by calling Structure::get(). This can lead
2008         to rematerialization of property tables, which is definitely not thread-safe
2009         due to how StringImpl works. So, this patch completely side-steps the problem
2010         by creating a new version of Structure::get, called
2011         Structure::getWithoutMaterializing, which may choose to do an O(n) search if
2012         necessary to avoid materialization. I believe this should be fine - the DFG
2013         does't call into these code path often enough for this to matter, and most of
2014         the time, the Structure that we call this on will already have a property
2015         table because some inline cache would have already called ::get() on that
2016         Structure.
2017         
2018         Also cleaned up the materialization logic: we can stop the search as soon as
2019         we find any Structure with a property table rather than searching all the way
2020         for a pinned one.
2021
2022         * bytecode/GetByIdStatus.cpp:
2023         (JSC::GetByIdStatus::computeFor):
2024         * bytecode/PutByIdStatus.cpp:
2025         (JSC::PutByIdStatus::computeFromLLInt):
2026         (JSC::PutByIdStatus::computeFor):
2027         * runtime/Structure.cpp:
2028         (JSC::Structure::findStructuresAndMapForMaterialization):
2029         (JSC::Structure::materializePropertyMap):
2030         (JSC::Structure::getWithoutMaterializing):
2031         (JSC):
2032         * runtime/Structure.h:
2033         (Structure):
2034         * runtime/StructureInlines.h:
2035         (JSC::Structure::getWithoutMaterializing):
2036         (JSC):
2037
2038 2013-04-13  Filip Pizlo  <fpizlo@apple.com>
2039
2040         fourthTier: Fix release build.
2041
2042         * dfg/DFGOSRExitCompilerCommon.cpp:
2043         * ftl/FTLExitValue.cpp:
2044         * ftl/FTLOSRExitCompiler.cpp:
2045
2046 2013-04-13  Filip Pizlo  <fpizlo@apple.com>
2047
2048         fourthTier: FTL should have OSR exit
2049         https://bugs.webkit.org/show_bug.cgi?id=113623
2050
2051         Reviewed by Oliver Hunt.
2052         
2053         This implements OSR exit, and hilariously, it actually works. The idea is to have
2054         LLVM call a no-return function on the off-ramp, passing it everything we know about
2055         bytecode state that isn't already flushed to the call frame. Our own JIT takes care
2056         of the rest.
2057         
2058         We can now run all of SunSpider, V8, and Kraken with the FTL enabled.
2059         
2060         The details are described in FTLOSRExit.h.
2061
2062         * CMakeLists.txt:
2063         * GNUmakefile.list.am:
2064         * JavaScriptCore.xcodeproj/project.pbxproj:
2065         * Target.pri:
2066         * assembler/AbstractMacroAssembler.h:
2067         (Address):
2068         (JSC::AbstractMacroAssembler::Address::withOffset):
2069         * assembler/LinkBuffer.h:
2070         (JSC::LinkBuffer::offsetOf):
2071         (LinkBuffer):
2072         * assembler/MacroAssemblerX86Common.h:
2073         * assembler/RepatchBuffer.h:
2074         (JSC::RepatchBuffer::RepatchBuffer):
2075         (JSC::RepatchBuffer::~RepatchBuffer):
2076         (RepatchBuffer):
2077         * bytecode/CodeBlock.cpp:
2078         (JSC::CodeBlock::tallyFrequentExitSites):
2079         * bytecode/Operands.h:
2080         (Operands):
2081         (JSC):
2082         (JSC::::dump):
2083         * dfg/DFGAbstractState.cpp:
2084         (JSC::DFG::AbstractState::initialize):
2085         * dfg/DFGGPRInfo.h:
2086         (DFG):
2087         (GPRInfo):
2088         * dfg/DFGMinifiedNode.h:
2089         (JSC::DFG::belongsInMinifiedGraph):
2090         * dfg/DFGNodeType.h:
2091         (JSC::DFG::needsOSRBackwardRewiring):
2092         (DFG):
2093         (JSC::DFG::needsOSRForwardRewiring):
2094         * dfg/DFGOSRExit.cpp:
2095         (JSC::DFG::OSRExit::OSRExit):
2096         (DFG):
2097         (JSC::DFG::OSRExit::convertToForward):
2098         * dfg/DFGOSRExit.h:
2099         (OSRExit):
2100         * dfg/DFGOSRExitBase.cpp: Added.
2101         (DFG):
2102         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSiteSlow):
2103         (JSC::DFG::OSRExitBase::doSearchForForwardConversion):
2104         * dfg/DFGOSRExitBase.h: Added.
2105         (DFG):
2106         (JSC::DFG::OSRExitBase::OSRExitBase):
2107         (OSRExitBase):
2108         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
2109         * dfg/DFGOSRExitCompiler.cpp:
2110         * dfg/DFGOSRExitCompiler64.cpp:
2111         (JSC::DFG::OSRExitCompiler::compileExit):
2112         * dfg/DFGOSRExitCompilerCommon.cpp:
2113         (JSC::DFG::handleExitCounts):
2114         (JSC::DFG::reifyInlinedCallFrames):
2115         (JSC::DFG::adjustAndJumpToTarget):
2116         * dfg/DFGOSRExitCompilerCommon.h:
2117         (DFG):
2118         * dfg/DFGOSRExitPreparation.cpp: Added.
2119         (DFG):
2120         (JSC::DFG::prepareCodeOriginForOSRExit):
2121         * dfg/DFGOSRExitPreparation.h: Added.
2122         (DFG):
2123         * dfg/DFGOperations.cpp:
2124         * dfg/DFGSpeculativeJIT.cpp:
2125         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
2126         * dfg/DFGValueSource.h:
2127         (JSC::DFG::ValueSource::forSpeculation):
2128         * dfg/DFGVariableEventStream.cpp:
2129         (JSC::DFG::VariableEventStream::reconstruct):
2130         * ftl/FTLAbbreviations.h:
2131         (JSC::FTL::functionType):
2132         (FTL):
2133         (JSC::FTL::typeOf):
2134         (JSC::FTL::appendBasicBlock):
2135         (JSC::FTL::insertBasicBlock):
2136         (JSC::FTL::buildCall):
2137         (JSC::FTL::setTailCall):
2138         * ftl/FTLCArgumentGetter.cpp: Added.
2139         (FTL):
2140         (JSC::FTL::CArgumentGetter::loadNextAndBox):
2141         * ftl/FTLCArgumentGetter.h: Added.
2142         (FTL):
2143         (JSC::FTL::isArgumentRegister):
2144         (CArgumentGetter):
2145         (JSC::FTL::CArgumentGetter::CArgumentGetter):
2146         (JSC::FTL::CArgumentGetter::loadNext8):
2147         (JSC::FTL::CArgumentGetter::loadNext32):
2148         (JSC::FTL::CArgumentGetter::loadNext64):
2149         (JSC::FTL::CArgumentGetter::loadNextPtr):
2150         (JSC::FTL::CArgumentGetter::loadNextDouble):
2151         (JSC::FTL::CArgumentGetter::nextAddress):
2152         * ftl/FTLCompile.cpp:
2153         (JSC::FTL::compile):
2154         * ftl/FTLExitArgument.cpp: Added.
2155         (FTL):
2156         (JSC::FTL::ExitArgument::dump):
2157         * ftl/FTLExitArgument.h: Added.
2158         (FTL):
2159         (ExitArgumentRepresentation):
2160         (ExitArgument):
2161         (JSC::FTL::ExitArgument::ExitArgument):
2162         (JSC::FTL::ExitArgument::operator!):
2163         (JSC::FTL::ExitArgument::format):
2164         (JSC::FTL::ExitArgument::argument):
2165         (JSC::FTL::ExitArgument::withFormat):
2166         (JSC::FTL::ExitArgument::representation):
2167         * ftl/FTLExitArgumentForOperand.cpp: Added.
2168         (FTL):
2169         (JSC::FTL::ExitArgumentForOperand::dump):
2170         * ftl/FTLExitArgumentForOperand.h: Added.
2171         (FTL):
2172         (ExitArgumentForOperand):
2173         (JSC::FTL::ExitArgumentForOperand::ExitArgumentForOperand):
2174         (JSC::FTL::ExitArgumentForOperand::operator!):
2175         (JSC::FTL::ExitArgumentForOperand::exitArgument):
2176         (JSC::FTL::ExitArgumentForOperand::operand):
2177         (JSC::FTL::lesserArgumentIndex):
2178         * ftl/FTLExitArgumentList.h: Added.
2179         (FTL):
2180         * ftl/FTLExitThunkGenerator.cpp: Added.
2181         (FTL):
2182         (JSC::FTL::ExitThunkGenerator::ExitThunkGenerator):
2183         (JSC::FTL::ExitThunkGenerator::~ExitThunkGenerator):
2184         (JSC::FTL::ExitThunkGenerator::emitThunk):
2185         * ftl/FTLExitThunkGenerator.h: Added.
2186         (FTL):
2187         (ExitThunkGenerator):
2188         (JSC::FTL::ExitThunkGenerator::didThings):
2189         * ftl/FTLExitValue.cpp: Added.
2190         (FTL):
2191         (JSC::FTL::ExitValue::dump):
2192         * ftl/FTLExitValue.h: Added.
2193         (FTL):
2194         (ExitValue):
2195         (JSC::FTL::ExitValue::ExitValue):
2196         (JSC::FTL::ExitValue::operator!):
2197         (JSC::FTL::ExitValue::dead):
2198         (JSC::FTL::ExitValue::inJSStack):
2199         (JSC::FTL::ExitValue::inJSStackAsInt32):
2200         (JSC::FTL::ExitValue::inJSStackAsDouble):
2201         (JSC::FTL::ExitValue::constant):
2202         (JSC::FTL::ExitValue::exitArgument):
2203         (JSC::FTL::ExitValue::kind):
2204         (JSC::FTL::ExitValue::isDead):
2205         (JSC::FTL::ExitValue::isInJSStackSomehow):
2206         (JSC::FTL::ExitValue::isConstant):
2207         (JSC::FTL::ExitValue::isArgument):
2208         * ftl/FTLFormattedValue.h:
2209         (FTL):
2210         (JSC::FTL::noValue):
2211         (JSC::FTL::int32Value):
2212         (JSC::FTL::uInt32Value):
2213         (JSC::FTL::booleanValue):
2214         (JSC::FTL::jsValueValue):
2215         (JSC::FTL::doubleValue):
2216         * ftl/FTLJITCode.cpp:
2217         (JSC::FTL::JITCode::initializeExitThunks):
2218         (FTL):
2219         (JSC::FTL::JITCode::exitThunks):
2220         * ftl/FTLJITCode.h:
2221         (JITCode):
2222         * ftl/FTLLowerDFGToLLVM.cpp:
2223         (FTL):
2224         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
2225         (JSC::FTL::LowerDFGToLLVM::lower):
2226         (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
2227         (JSC::FTL::LowerDFGToLLVM::compileBlock):
2228         (JSC::FTL::LowerDFGToLLVM::compileNode):
2229         (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
2230         (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
2231         (LowerDFGToLLVM):
2232         (JSC::FTL::LowerDFGToLLVM::compileMovHint):
2233         (JSC::FTL::LowerDFGToLLVM::compileZombieHint):
2234         (JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck):
2235         (JSC::FTL::LowerDFGToLLVM::compileAdd):
2236         (JSC::FTL::LowerDFGToLLVM::compileArithSub):
2237         (JSC::FTL::LowerDFGToLLVM::compileArithMul):
2238         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2239         (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
2240         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
2241         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2242         (JSC::FTL::LowerDFGToLLVM::speculateBackward):
2243         (JSC::FTL::LowerDFGToLLVM::speculateForward):
2244         (JSC::FTL::LowerDFGToLLVM::speculate):
2245         (JSC::FTL::LowerDFGToLLVM::terminate):
2246         (JSC::FTL::LowerDFGToLLVM::backwardTypeCheck):
2247         (JSC::FTL::LowerDFGToLLVM::forwardTypeCheck):
2248         (JSC::FTL::LowerDFGToLLVM::typeCheck):
2249         (JSC::FTL::LowerDFGToLLVM::appendTypeCheck):
2250         (JSC::FTL::LowerDFGToLLVM::lowInt32):
2251         (JSC::FTL::LowerDFGToLLVM::lowCell):
2252         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
2253         (JSC::FTL::LowerDFGToLLVM::speculateObject):
2254         (JSC::FTL::LowerDFGToLLVM::isLive):
2255         (JSC::FTL::LowerDFGToLLVM::use):
2256         (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
2257         (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
2258         (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
2259         (JSC::FTL::LowerDFGToLLVM::tryToSetConstantExitArgument):
2260         (JSC::FTL::LowerDFGToLLVM::addExitArgument):
2261         (JSC::FTL::LowerDFGToLLVM::linkOSRExitsAndCompleteInitializationBlocks):
2262         (JSC::FTL::LowerDFGToLLVM::observeMovHint):
2263         * ftl/FTLOSRExit.cpp: Added.
2264         (FTL):
2265         (JSC::FTL::OSRExit::OSRExit):
2266         (JSC::FTL::OSRExit::codeLocationForRepatch):
2267         (JSC::FTL::OSRExit::convertToForward):
2268         * ftl/FTLOSRExit.h: Added.
2269         (FTL):
2270         (OSRExit):
2271         * ftl/FTLOSRExitCompilationInfo.h: Added.
2272         (FTL):
2273         (JSC::FTL::OSRExitCompilationInfo::OSRExitCompilationInfo):
2274         (OSRExitCompilationInfo):
2275         * ftl/FTLOSRExitCompiler.cpp: Added.
2276         (FTL):
2277         (JSC::FTL::compileStub):
2278         (JSC::FTL::compileFTLOSRExit):
2279         * ftl/FTLOSRExitCompiler.h: Added.
2280         (FTL):
2281         * ftl/FTLOutput.h:
2282         (JSC::FTL::Output::newBlock):
2283         (JSC::FTL::Output::intToPtr):
2284         (JSC::FTL::Output::load):
2285         (JSC::FTL::Output::store):
2286         (Output):
2287         (JSC::FTL::Output::call):
2288         (JSC::FTL::Output::convertToTailCall):
2289         (FTL):
2290         * ftl/FTLState.h:
2291         (State):
2292         * ftl/FTLThunks.cpp: Added.
2293         (FTL):
2294         (JSC::FTL::osrExitGenerationThunkGenerator):
2295         * ftl/FTLThunks.h: Added.
2296         (JSC):
2297         (FTL):
2298         * ftl/FTLValueFormat.cpp: Added.
2299         (WTF):
2300         (WTF::printInternal):
2301         * ftl/FTLValueFormat.h: Added.
2302         (FTL):
2303         (WTF):
2304         * ftl/FTLValueSource.cpp: Added.
2305         (FTL):
2306         (JSC::FTL::ValueSource::dump):
2307         * ftl/FTLValueSource.h: Added.
2308         (FTL):
2309         (ValueSource):
2310         (JSC::FTL::ValueSource::ValueSource):
2311         (JSC::FTL::ValueSource::kind):
2312         (JSC::FTL::ValueSource::operator!):
2313         (JSC::FTL::ValueSource::node):
2314
2315 2013-04-12  Filip Pizlo  <fpizlo@apple.com>
2316
2317         fourthTier: switch to using MCJIT and disable frame pointer elimination
2318         https://bugs.webkit.org/show_bug.cgi?id=114542
2319
2320         Reviewed by Oliver Hunt and Michael Saboff.
2321
2322         * ftl/FTLCompile.cpp:
2323         (JSC::FTL::compile):
2324         * runtime/InitializeThreading.cpp:
2325         (JSC::initializeThreadingOnce):
2326
2327 2013-04-09  Filip Pizlo  <fpizlo@apple.com>
2328
2329         fourthTier: DFG should provide utilities for common OSR exit tasks
2330         https://bugs.webkit.org/show_bug.cgi?id=114306
2331
2332         Reviewed by Mark Hahnenberg.
2333         
2334         Just abstract out some things that the FTL will want to use as well.
2335
2336         * CMakeLists.txt:
2337         * GNUmakefile.list.am:
2338         * JavaScriptCore.xcodeproj/project.pbxproj:
2339         * Target.pri:
2340         * dfg/DFGDriver.cpp:
2341         (JSC::DFG::compile):
2342         * dfg/DFGOSRExitCompiler.cpp:
2343         * dfg/DFGOSRExitCompiler.h:
2344         (OSRExitCompiler):
2345         * dfg/DFGOSRExitCompiler32_64.cpp:
2346         (JSC::DFG::OSRExitCompiler::compileExit):
2347         * dfg/DFGOSRExitCompiler64.cpp:
2348         (JSC::DFG::OSRExitCompiler::compileExit):
2349         * dfg/DFGOSRExitCompilerCommon.cpp: Added.
2350         (DFG):
2351         (JSC::DFG::handleExitCounts):
2352         (JSC::DFG::reifyInlinedCallFrames):
2353         (JSC::DFG::adjustAndJumpToTarget):
2354         * dfg/DFGOSRExitCompilerCommon.h: Added.
2355         (DFG):
2356
2357 2013-04-09  Filip Pizlo  <fpizlo@apple.com>
2358
2359         fourthTier: DFG should better abstract floating point arguments
2360         https://bugs.webkit.org/show_bug.cgi?id=114300
2361
2362         Reviewed by Mark Hahnenberg.
2363
2364         * dfg/DFGFPRInfo.h:
2365         (FPRInfo):
2366         (JSC::DFG::FPRInfo::toArgumentRegister):
2367
2368 2013-04-05  Filip Pizlo  <fpizlo@apple.com>
2369
2370         fourthTier: DFG should better abstract arguments
2371         https://bugs.webkit.org/show_bug.cgi?id=114073
2372
2373         Reviewed by Mark Hahnenberg.
2374
2375         * dfg/DFGGPRInfo.h:
2376         (GPRInfo):
2377         (JSC::DFG::GPRInfo::toArgumentRegister):
2378
2379 2013-04-03  Filip Pizlo  <fpizlo@apple.com>
2380
2381         fourthTier: put DFG data into a DFG::JITCode, and put common DFG and FTL data into something accessible from both DFG::JITCode and FTL::JITCode
2382         https://bugs.webkit.org/show_bug.cgi?id=113905
2383
2384         Reviewed by Geoffrey Garen.
2385         
2386         This removes one pointer from CodeBlock.
2387         
2388         It also gives us a framework for having JITType-specific data in CodeBlock, by
2389         putting it into the appropriate JITCode class (either DFG::JITCode or
2390         FTL::JITCode). And it allows us to have DFG and FTL share some common data,
2391         via DFG::CommonData, which is stored in both DFG::JITCode and FTL::JITCode and
2392         always accessible via JITCode::dfgCommon().
2393
2394         * CMakeLists.txt:
2395         * GNUmakefile.list.am:
2396         * JavaScriptCore.xcodeproj/project.pbxproj:
2397         * Target.pri:
2398         * bytecode/CodeBlock.cpp:
2399         (JSC):
2400         (JSC::CodeBlock::dumpBytecode):
2401         (JSC::CodeBlock::visitAggregate):
2402         (JSC::CodeBlock::performTracingFixpointIteration):
2403         (JSC::CodeBlock::finalizeUnconditionally):
2404         (JSC::CodeBlock::stronglyVisitWeakReferences):
2405         (JSC::CodeBlock::shrinkToFit):
2406         (JSC::CodeBlock::tallyFrequentExitSites):
2407         * bytecode/CodeBlock.h:
2408         (CodeBlock):
2409         (JSC::CodeBlock::setJITCode):
2410         (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
2411         (JSC::DFGCodeBlocks::mark):
2412         * dfg/DFGAssemblyHelpers.h:
2413         * dfg/DFGCommonData.cpp: Added.
2414         (DFG):
2415         (JSC::DFG::CommonData::notifyCompilingStructureTransition):
2416         (JSC::DFG::CommonData::shrinkToFit):
2417         * dfg/DFGCommonData.h: Added.
2418         (JSC):
2419         (DFG):
2420         (JSC::DFG::WeakReferenceTransition::WeakReferenceTransition):
2421         (WeakReferenceTransition):
2422         (CommonData):
2423         (JSC::DFG::CommonData::CommonData):
2424         * dfg/DFGDriver.cpp:
2425         (JSC::DFG::compile):
2426         (JSC::DFG::tryCompile):
2427         (JSC::DFG::tryCompileFunction):
2428         * dfg/DFGDriver.h:
2429         (DFG):
2430         (JSC::DFG::tryCompile):
2431         (JSC::DFG::tryCompileFunction):
2432         * dfg/DFGGraph.h:
2433         (Graph):
2434         * dfg/DFGJITCode.cpp: Added.
2435         (DFG):
2436         (JSC::DFG::JITCode::JITCode):
2437         (JSC::DFG::JITCode::~JITCode):
2438         (JSC::DFG::JITCode::dfgCommon):
2439         (JSC::DFG::JITCode::dfg):
2440         (JSC::DFG::JITCode::shrinkToFit):
2441         * dfg/DFGJITCode.h: Added.
2442         (DFG):
2443         (JITCode):
2444         (JSC::DFG::JITCode::appendOSREntryData):
2445         (JSC::DFG::JITCode::osrEntryDataForBytecodeIndex):
2446         (JSC::DFG::JITCode::appendOSRExit):
2447         (JSC::DFG::JITCode::lastOSRExit):
2448         (JSC::DFG::JITCode::appendSpeculationRecovery):
2449         (JSC::DFG::JITCode::appendWatchpoint):
2450         * dfg/DFGJITCompiler.cpp:
2451         (JSC::DFG::JITCompiler::JITCompiler):
2452         (JSC::DFG::JITCompiler::linkOSRExits):
2453         (JSC::DFG::JITCompiler::link):
2454         (JSC::DFG::JITCompiler::compile):
2455         (JSC::DFG::JITCompiler::compileFunction):
2456         * dfg/DFGJITCompiler.h:
2457         (JITCompiler):
2458         (JSC::DFG::JITCompiler::addWeakReference):
2459         (JSC::DFG::JITCompiler::noticeOSREntry):
2460         (JSC::DFG::JITCompiler::jitCode):
2461         * dfg/DFGOSREntry.cpp:
2462         (JSC::DFG::prepareOSREntry):
2463         * dfg/DFGOSRExit.h:
2464         (OSRExit):
2465         * dfg/DFGOSRExitCompiler.cpp:
2466         * dfg/DFGSpeculativeJIT.cpp:
2467         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
2468         (JSC::DFG::SpeculativeJIT::backwardSpeculationCheck):
2469         (JSC::DFG::SpeculativeJIT::speculationWatchpoint):
2470         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
2471         * dfg/DFGSpeculativeJIT32_64.cpp:
2472         (JSC::DFG::SpeculativeJIT::compile):
2473         * dfg/DFGSpeculativeJIT64.cpp:
2474         (JSC::DFG::SpeculativeJIT::compile):
2475         * dfg/DFGVariableEventStream.cpp:
2476         * ftl/FTLCompile.cpp:
2477         (JSC::FTL::compile):
2478         * ftl/FTLJITCode.cpp:
2479         (JSC::FTL::JITCode::JITCode):
2480         (JSC::FTL::JITCode::~JITCode):
2481         (FTL):
2482         (JSC::FTL::JITCode::initializeCode):
2483         (JSC::FTL::JITCode::addressForCall):
2484         (JSC::FTL::JITCode::executableAddressAtOffset):
2485         (JSC::FTL::JITCode::dataAddressAtOffset):
2486         (JSC::FTL::JITCode::offsetOf):
2487         (JSC::FTL::JITCode::size):
2488         (JSC::FTL::JITCode::contains):
2489         (JSC::FTL::JITCode::ftl):
2490         (JSC::FTL::JITCode::dfgCommon):
2491         * ftl/FTLJITCode.h:
2492         (JITCode):
2493         * ftl/FTLLowerDFGToLLVM.cpp:
2494         (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
2495         (JSC::FTL::LowerDFGToLLVM::compilePutStructure):
2496         (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
2497         (JSC::FTL::LowerDFGToLLVM::addWeakReference):
2498         (LowerDFGToLLVM):
2499         (JSC::FTL::LowerDFGToLLVM::weakPointer):
2500         * ftl/FTLState.cpp:
2501         (FTL):
2502         (JSC::FTL::State::State):
2503         (JSC::FTL::State::dumpState):
2504         * ftl/FTLState.h:
2505         (State):
2506         * heap/DFGCodeBlocks.cpp:
2507         (JSC::DFGCodeBlocks::~DFGCodeBlocks):
2508         (JSC::DFGCodeBlocks::jettison):
2509         (JSC::DFGCodeBlocks::clearMarks):
2510         (JSC::DFGCodeBlocks::deleteUnmarkedJettisonedCodeBlocks):
2511         (JSC::DFGCodeBlocks::traceMarkedCodeBlocks):
2512         * jit/JITCode.cpp:
2513         (JSC::JITCode::dfgCommon):
2514         (JSC):
2515         (JSC::JITCode::dfg):
2516         (JSC::JITCode::ftl):
2517         (JSC::DirectJITCode::DirectJITCode):
2518         (JSC::DirectJITCode::initializeCodeRef):
2519         (JSC::DirectJITCode::addressForCall):
2520         (JSC::DirectJITCode::executableAddressAtOffset):
2521         (JSC::DirectJITCode::dataAddressAtOffset):
2522         (JSC::DirectJITCode::offsetOf):
2523         (JSC::DirectJITCode::size):
2524         (JSC::DirectJITCode::contains):
2525         * jit/JITCode.h:
2526         (DFG):
2527         (FTL):
2528         (JSC):
2529         (JITCode):
2530         (DirectJITCode):
2531
2532 2013-04-03  Filip Pizlo  <fpizlo@apple.com>
2533
2534         fourthTier: Include LLVM headers with surrounding #pragmas instead of using my #define
2535         https://bugs.webkit.org/show_bug.cgi?id=113921
2536
2537         Reviewed by Oliver Hunt.
2538         
2539         The LLVM community wants us to continue including all of LLVM's C++ headers. Change
2540         to using #pragma's to disable warnings that they cannot handle.
2541
2542         * ftl/FTLLLVMHeaders.h:
2543
2544 2013-04-03  Filip Pizlo  <fpizlo@apple.com>
2545
2546         fourthTier: Everyone should know about the FTL
2547         https://bugs.webkit.org/show_bug.cgi?id=113897
2548
2549         Reviewed by Mark Hahnenberg.
2550         
2551         In order to get OSR exit to work right, we need the distinction between DFG and
2552         FTL to be clear even after compilation finishes, since they will have subtly
2553         different OSR stories and likely use different data structures.
2554
2555         * bytecode/CodeBlock.cpp:
2556         (JSC::CodeBlock::resetStubInternal):
2557         (JSC::ProgramCodeBlock::compileOptimized):
2558         (JSC::EvalCodeBlock::compileOptimized):
2559         (JSC::FunctionCodeBlock::compileOptimized):
2560         (JSC::CodeBlock::adjustedExitCountThreshold):
2561         (JSC::CodeBlock::tallyFrequentExitSites):
2562         * bytecode/CodeBlock.h:
2563         (JSC::CodeBlock::setJITCode):
2564         (JSC::CodeBlock::hasOptimizedReplacement):
2565         (JSC::ExecState::isInlineCallFrame):
2566         * ftl/FTLCompile.cpp:
2567         (JSC::FTL::compile):
2568         * ftl/FTLJITCode.cpp:
2569         (JSC::FTL::JITCode::JITCode):
2570         * ftl/FTLState.cpp:
2571         (JSC::FTL::State::dumpState):
2572         * heap/DFGCodeBlocks.cpp:
2573         (JSC::DFGCodeBlocks::jettison):
2574         * interpreter/Interpreter.cpp:
2575         (JSC::getLineNumberForCallFrame):
2576         (JSC::getCallerInfo):
2577         * jit/JITCode.cpp:
2578         (WTF::printInternal):
2579         * jit/JITCode.h:
2580         (JSC::JITCode::topTierJIT):
2581         (JSC::JITCode::nextTierJIT):
2582         (JITCode):
2583         (JSC::JITCode::isJIT):
2584         (JSC::JITCode::isLowerTier):
2585         (JSC::JITCode::isHigherTier):
2586         (JSC::JITCode::isLowerOrSameTier):
2587         (JSC::JITCode::isHigherOrSameTier):
2588         (JSC::JITCode::isOptimizingJIT):
2589         * jit/JITDriver.h:
2590         (JSC::jitCompileIfAppropriate):
2591         (JSC::jitCompileFunctionIfAppropriate):
2592         * jit/JITStubs.cpp:
2593         (JSC::DEFINE_STUB_FUNCTION):
2594         * runtime/Executable.cpp:
2595         (JSC::EvalExecutable::compileOptimized):
2596         (JSC::samplingDescription):
2597         (JSC::ProgramExecutable::compileOptimized):
2598         (JSC::FunctionExecutable::compileOptimizedForCall):
2599         (JSC::FunctionExecutable::compileOptimizedForConstruct):
2600
2601 2013-04-03  Filip Pizlo  <fpizlo@apple.com>
2602
2603         fourthTier: DFG should abstract out how it does forward exits, and that code should be simplified
2604         https://bugs.webkit.org/show_bug.cgi?id=113894
2605
2606         Reviewed by Mark Hahnenberg.
2607         
2608         1) We previously had two different ways of convertingToForward, one path for
2609            where we had a ValueRecovery for the current node and one where we didn't.
2610            But the paths were doing exactly the same thing except that if you have a
2611            ValueRecovery, you also find the last applicable mov hint and do some
2612            extra things. This patch combines the two paths and bases both of them on
2613            the previous no-ValueRecovery path, which was simpler to begin with.
2614         
2615         2) This moves the logic into DFG::OSRExit, which further simplifies the code
2616            and makes the logic available to the FTL.
2617
2618         * dfg/DFGOSRExit.cpp:
2619         (JSC::DFG::OSRExit::convertToForward):
2620         (DFG):
2621         * dfg/DFGOSRExit.h:
2622         (DFG):
2623         (OSRExit):
2624         * dfg/DFGSpeculativeJIT.cpp:
2625         (JSC::DFG::SpeculativeJIT::convertLastOSRExitToForward):
2626
2627 2013-04-02  Filip Pizlo  <fpizlo@apple.com>
2628
2629         fourthTier: FTL should have the equivalent of a ValueRecovery
2630         https://bugs.webkit.org/show_bug.cgi?id=113819
2631
2632         Reviewed by Mark Hahnenberg.
2633         
2634         This adds a way of saying that we have a value, we don't want to say what
2635         node the value came from, but we know specifics of how the value is
2636         formatted. This is the LLVM equivalent of DFG's ValueRecovery.
2637
2638         * JavaScriptCore.xcodeproj/project.pbxproj:
2639         * ftl/FTLFormattedValue.h: Added.
2640         (FTL):
2641         (FormattedValue):
2642         (JSC::FTL::FormattedValue::FormattedValue):
2643         (JSC::FTL::FormattedValue::operator!):
2644         (JSC::FTL::FormattedValue::format):
2645         (JSC::FTL::FormattedValue::value):
2646         * ftl/FTLLowerDFGToLLVM.cpp:
2647         (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
2648         (JSC::FTL::LowerDFGToLLVM::speculateForward):
2649         (JSC::FTL::LowerDFGToLLVM::weakPointer):
2650
2651 2013-04-02  Filip Pizlo  <fpizlo@apple.com>
2652
2653         fourthTier: FTL should use the right abstract heap for Int32 array accesses
2654         https://bugs.webkit.org/show_bug.cgi?id=113759
2655
2656         Reviewed by Mark Hahnenberg.
2657
2658         * ftl/FTLLowerDFGToLLVM.cpp:
2659         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2660
2661 2013-04-02  Filip Pizlo  <fpizlo@apple.com>
2662
2663         fourthTier: FTL should support fast property stores
2664         https://bugs.webkit.org/show_bug.cgi?id=113757
2665
2666         Reviewed by Oliver Hunt.
2667         
2668         Simplified the task of handling property transitions and reduced amount of code
2669         duplication between the JITs.
2670         
2671         Added PutByOffset, PutStructure, PhantomPutStructure, WeakJSConstant, and a
2672         stub form of StructureTransitionWatchpoint to the FTL.
2673         
2674         Also simplified the creation of pointer constants, and fixed a bug in
2675         speculateObject().
2676
2677         * dfg/DFGGraph.h:
2678         (JSC::DFG::Graph::notifyCompilingStructureTransition):
2679         (Graph):
2680         * dfg/DFGJITCompiler.h:
2681         (JITCompiler):
2682         * dfg/DFGSpeculativeJIT32_64.cpp:
2683         (JSC::DFG::SpeculativeJIT::compile):
2684         * dfg/DFGSpeculativeJIT64.cpp:
2685         (JSC::DFG::SpeculativeJIT::compile):
2686         * ftl/FTLCapabilities.cpp:
2687         (JSC::FTL::canCompile):
2688         * ftl/FTLLowerDFGToLLVM.cpp:
2689         (JSC::FTL::LowerDFGToLLVM::lower):
2690         (JSC::FTL::LowerDFGToLLVM::compileNode):
2691         (JSC::FTL::LowerDFGToLLVM::compileWeakJSConstant):
2692         (LowerDFGToLLVM):
2693         (JSC::FTL::LowerDFGToLLVM::compileStructureTransitionWatchpoint):
2694         (JSC::FTL::LowerDFGToLLVM::compilePutStructure):
2695         (JSC::FTL::LowerDFGToLLVM::compilePhantomPutStructure):
2696         (JSC::FTL::LowerDFGToLLVM::compilePutByOffset):
2697         (JSC::FTL::LowerDFGToLLVM::speculateObject):
2698         (JSC::FTL::LowerDFGToLLVM::weakPointer):
2699         * ftl/FTLOutput.h:
2700         (Output):
2701         (JSC::FTL::Output::constIntPtr):
2702         (JSC::FTL::Output::absolute):
2703
2704 2013-04-01  Filip Pizlo  <fpizlo@apple.com>
2705
2706         fourthTier: FTL should support some more integer arithmetic ops (negate, xor, urshift)
2707         https://bugs.webkit.org/show_bug.cgi?id=113740
2708
2709         Reviewed by Geoffrey Garen.
2710
2711         * ftl/FTLAbbreviations.h:
2712         (JSC::FTL::buildNeg):
2713         (JSC::FTL::buildLShr):
2714         * ftl/FTLCapabilities.cpp:
2715         (JSC::FTL::canCompile):
2716         * ftl/FTLLowerDFGToLLVM.cpp:
2717         (JSC::FTL::LowerDFGToLLVM::compileNode):
2718         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2719         (LowerDFGToLLVM):
2720         (JSC::FTL::LowerDFGToLLVM::compileBitXor):
2721         (JSC::FTL::LowerDFGToLLVM::compileBitURShift):
2722         (JSC::FTL::LowerDFGToLLVM::compileUInt32ToNumber):
2723         * ftl/FTLOutput.h:
2724         (JSC::FTL::Output::neg):
2725         (JSC::FTL::Output::lShr):
2726
2727 2013-04-01  Filip Pizlo  <fpizlo@apple.com>
2728
2729         fourthTier: FTL should support GetGlobalVar/PutGlobalVar
2730         https://bugs.webkit.org/show_bug.cgi?id=113728
2731
2732         Reviewed by Gavin Barraclough.
2733         
2734         Removed the macro magic for the globals absolute abstract heap, since for anything
2735         with absolute addresses we can just share a common absolute abstract heap. It
2736         would only be a problem if we for example were emitting an access to a global but
2737         not using an absolute address, and then wanted to say that this access was
2738         constrained to global variables. I don't believe we do that, and I don't believe we
2739         ever will.
2740         
2741         Then added Output::absolute(), a convenient way of building a typed pointer for an
2742         absolute address.
2743         
2744         Then added GetGlobalVar/PutGlobalVar.
2745
2746         * ftl/FTLAbstractHeapRepository.cpp:
2747         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
2748         * ftl/FTLAbstractHeapRepository.h:
2749         (FTL):
2750         (AbstractHeapRepository):
2751         * ftl/FTLCapabilities.cpp:
2752         (JSC::FTL::canCompile):
2753         * ftl/FTLLowerDFGToLLVM.cpp:
2754         (JSC::FTL::LowerDFGToLLVM::compileNode):
2755         (JSC::FTL::LowerDFGToLLVM::compileGetGlobalVar):
2756         (LowerDFGToLLVM):
2757         (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
2758         * ftl/FTLOutput.h:
2759         (JSC::FTL::Output::absolute):
2760         (Output):
2761
2762 2013-03-31  Filip Pizlo  <fpizlo@apple.com>
2763
2764         fourthTier: FTL should support ArithSub
2765         https://bugs.webkit.org/show_bug.cgi?id=113675
2766
2767         Reviewed by Oliver Hunt.
2768         
2769         This does the obvious bit of implementing ArithSub, but it also takes this
2770         as an opportunity to clean up how intrinsics and common values (common types
2771         and constants) are handled. Previously they were all lumped together in
2772         FTL::Output. Now, in an effort to split up the files and make FTL::Output
2773         less big, I created a thing called FTL::CommonValues which just tracks the
2774         common values, and a thing called FTL::IntrinsicRepository which just tracks
2775         intrinsics. These and FTL::Output are all related to each other in a linear
2776         hierarchy. Moreover, IntrinsicRepository uses macro-fu to make it easy to
2777         declare new intrinsics in the future.
2778         
2779         I also out-of-lined some things and made .cpp files for each of these classes.
2780         Initialize I wasn't going to do this but then I realized that FTL::Output is
2781         already included in multiple places. Probably it's better if some of its guts
2782         are not inline, and it's also good to now have .cpp "landing pads" if we ever
2783         want to add more things to that class.
2784         
2785         Note that a lot of how these things are designed has to do with the fact
2786         that pretty soon here I'll have to switch us from using the LLVM global
2787         context to using a context that we create. When that happens, anyone who
2788         creates anything will have to know the context; that's why FTL::CommonValues
2789         already knows the module but doesn't use it - in the future it will have to
2790         do things with it.
2791
2792         * JavaScriptCore.xcodeproj/project.pbxproj:
2793         * ftl/FTLAbbreviations.h:
2794         (JSC::FTL::buildSub):
2795         * ftl/FTLAbstractHeapRepository.cpp:
2796         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
2797         * ftl/FTLCapabilities.cpp:
2798         (JSC::FTL::canCompile):
2799         * ftl/FTLCommonValues.cpp: Added.
2800         (FTL):
2801         (JSC::FTL::CommonValues::CommonValues):
2802         * ftl/FTLCommonValues.h: Added.
2803         (FTL):
2804         (CommonValues):
2805         (JSC::FTL::CommonValues::initialize):
2806         * ftl/FTLIntrinsicRepository.cpp: Added.
2807         (FTL):
2808         (JSC::FTL::IntrinsicRepository::IntrinsicRepository):
2809         * ftl/FTLIntrinsicRepository.h: Added.
2810         (FTL):
2811         (IntrinsicRepository):
2812         * ftl/FTLLowerDFGToLLVM.cpp:
2813         (JSC::FTL::LowerDFGToLLVM::compileNode):
2814         (JSC::FTL::LowerDFGToLLVM::compileArithSub):
2815         (LowerDFGToLLVM):
2816         * ftl/FTLOutput.cpp: Added.
2817         (FTL):
2818         (JSC::FTL::Output::Output):
2819         (JSC::FTL::Output::~Output):
2820         * ftl/FTLOutput.h:
2821         (Output):
2822         (JSC::FTL::Output::initialize):
2823         (JSC::FTL::Output::sub):
2824         (JSC::FTL::Output::addWithOverflow32):
2825         (JSC::FTL::Output::subWithOverflow32):
2826         (JSC::FTL::Output::mulWithOverflow32):
2827
2828 2013-03-31  Filip Pizlo  <fpizlo@apple.com>
2829
2830         fourthTier: FTL doesn't need virtual register allocation
2831         https://bugs.webkit.org/show_bug.cgi?id=113679
2832
2833         Reviewed by Mark Hahnenberg.
2834
2835         * dfg/DFGDriver.cpp:
2836         (JSC::DFG::dumpAndVerifyGraph):
2837         (DFG):
2838         (JSC::DFG::compile):
2839
2840 2013-03-31  Filip Pizlo  <fpizlo@apple.com>
2841
2842         https://bugs.webkit.org/show_bug.cgi?id=113656
2843         Fix Sam's nits.
2844
2845         Unreviewed.
2846
2847         * ftl/FTLAbstractHeap.cpp:
2848         (JSC::FTL::IndexedAbstractHeap::initialize):
2849         * ftl/FTLAbstractHeap.h:
2850         (IndexedAbstractHeap):
2851         (AbsoluteAbstractHeap):
2852         * ftl/FTLAbstractHeapRepository.h:
2853         (AbstractHeapRepository):
2854
2855 2013-03-31  Filip Pizlo  <fpizlo@apple.com>
2856
2857         fourthTier: FTL JIT should support GetByVal on Int32 arrays
2858         https://bugs.webkit.org/show_bug.cgi?id=113668
2859
2860         Reviewed by Sam Weinig.
2861         
2862         It actually already supported this, but needed to be told that it did.
2863         
2864         Also adds an option to enable LICM (loop-invariant code motion, i.e.
2865         http://llvm.org/docs/Passes.html#licm-loop-invariant-code-motion). LICM
2866         isn't doing me any good right now, but I guess I'll have to play with
2867         it more. And this adds the ability to tweak the LLVM optimization level
2868         from the command-line.
2869
2870         * ftl/FTLCapabilities.cpp:
2871         (JSC::FTL::canCompile):
2872         * ftl/FTLCompile.cpp:
2873         (JSC::FTL::compile):
2874         * ftl/FTLLowerDFGToLLVM.cpp:
2875         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
2876         * runtime/Options.h:
2877         (JSC):
2878
2879 2013-03-31  Filip Pizlo  <fpizlo@apple.com>
2880
2881         fourthTier: FTL JIT should supply TBAA meta-data to LLVM
2882         https://bugs.webkit.org/show_bug.cgi?id=113656
2883
2884         Reviewed by Oliver Hunt.
2885         
2886         This adds support for performing strong typing on the LLVM IR that the FTL
2887         generates, by using TBAA meta-data. This will permit LLVM to do aggressive
2888         GVN, load elimination, and LICM optimization even if it sees pointer store
2889         side-effects. The goal is to precisely model all loads and stores we emit,
2890         except for the super crazy ones (GetById that can go all-out polymorphic,
2891         or for example a Call where we know nothing).
2892         
2893         This is accomplished by introducing the notion of an AbstractHeap
2894         typesystem. An AbstractHeap is a subset of all possible memory locations
2895         that we might store to. For example, JSCell::m_structure and
2896         JSObject::m_butterfly are two disjoint AbstractHeaps because we know that
2897         a store to one cannot clobber the other. AbstractHeaps follow a
2898         single-inheritance hierarchy. There is the root heap, which corresponds to
2899         any possible memory location accessible to the JS engine, and then there
2900         are heaps for all internal object fields, a heap for each global object,
2901         and so on.
2902         
2903         There are three other tidbits here that make this somewhat more interesting.
2904         We have a notion of an AbstractHeap-with-offset, called AbstractField.
2905         JSCell::m_structure is actually an AbstractField. This allows us to say
2906         things like m_out.loadPtr(base, m_heaps.JSCell_structure); this both
2907         gives you the offset of JSCell::m_structure and ascribes TBAA meta-data for
2908         the JSCell::m_structure heap to the generated load instrction.
2909         
2910         Another fun tidbit is the notion of Indexed, Numbered, and Absolute abstract
2911         heaps. An indexed abstract heap corresponds to a set of locations that you
2912         might access by index from some base. Virtual registers are a great example.
2913         Though I call them just "variables" in the FTL. When we access a virtual
2914         register, we know that we aren't interfering with accesses to
2915         Structure-managed named properties, or with JSCell::m_structure, or with
2916         other such disjoint heaps. But we also know that if we access a variable at
2917         offset X and then another variable at offset Y and we know that X and Y are
2918         unequal, then these two accesses are on disjoint subheaps of the variables
2919         heap. This works out naturally for interference between, say, scoped variable
2920         access and local variable access: if you access scoped variable r5 and then
2921         access a local variable r5, these might interfere - and they will get the
2922         same abstract subheap of the variables heap. IndexedAbstractHeaps
2923         conveniently remember the size of the elements and will give you an
2924         AbstractField (i.e. heap-with-offset) if you give it an index. This is great
2925         for conveniently writing code that accesses contiguous arrays of well-typed
2926         things. This allows you to literally do things like
2927         m_out.load64(callFrameRegister, m_heaps.variables[operand]) and the right
2928         thing will happen. You can also get the heap variables.atAnyIndex(), if
2929         you're doing an access with an unknown index.
2930         
2931         Numbered and Absolute abstract heaps are related except that they don't
2932         assume that the value used to get the abstract subheap corresponds to any
2933         meaningful offset from any base. Numbered heaps, like the properties heap
2934         (for named properties tracked by Structure), are "numbered" (not indexed)
2935         by the propertyNumber. So you can emit a GetByOffset by separately
2936         computing the offset and the propertyNumber (both values are stored in the
2937         StorageAccessData), and passing the offset directly to Output::address()
2938         and passing m_heaps.properties[propertyNumber] as the field. Absolute heaps
2939         are similar, but are keyed on absolute address. This is appropriate for
2940         global variables, and possibly other things.
2941         
2942         Finally, FTL::Output understands the notion of a pointer-with-TBAA-data,
2943         and calls it a TypedPointer. TypedPointer is a tuple of a LLVMValueRef
2944         referencing an intptr value and a pointer to an AbstractHeap. All load()
2945         and store() operations now take a TypedPointer, and will perform the access
2946         by casting the intptr to a pointer of the right type and then ascribing the
2947         TBAA meta-data from the AbstractHeap.
2948
2949         * JavaScriptCore.xcodeproj/project.pbxproj:
2950         * ftl/FTLAbbreviations.h:
2951         (JSC::FTL::mdKindID):
2952         (JSC::FTL::mdString):
2953         (JSC::FTL::mdNode):
2954         (FTL):
2955         (JSC::FTL::setMetadata):
2956         * ftl/FTLAbstractHeap.cpp: Added.
2957         (FTL):
2958         (JSC::FTL::AbstractHeap::tbaaMetadataSlow):
2959         (JSC::FTL::AbstractHeap::decorateInstruction):
2960         (JSC::FTL::IndexedAbstractHeap::IndexedAbstractHeap):
2961         (JSC::FTL::IndexedAbstractHeap::~IndexedAbstractHeap):
2962         (JSC::FTL::IndexedAbstractHeap::baseIndex):
2963         (JSC::FTL::IndexedAbstractHeap::atSlow):
2964         (JSC::FTL::IndexedAbstractHeap::initialize):
2965         (JSC::FTL::NumberedAbstractHeap::NumberedAbstractHeap):
2966         (JSC::FTL::NumberedAbstractHeap::~NumberedAbstractHeap):
2967         (JSC::FTL::AbsoluteAbstractHeap::AbsoluteAbstractHeap):
2968         (JSC::FTL::AbsoluteAbstractHeap::~AbsoluteAbstractHeap):
2969         * ftl/FTLAbstractHeap.h: Added.
2970         (FTL):
2971         (AbstractHeap):
2972         (JSC::FTL::AbstractHeap::AbstractHeap):
2973         (JSC::FTL::AbstractHeap::isInitialized):
2974         (JSC::FTL::AbstractHeap::initialize):
2975         (JSC::FTL::AbstractHeap::parent):
2976         (JSC::FTL::AbstractHeap::heapName):
2977         (JSC::FTL::AbstractHeap::tbaaMetadata):
2978         (AbstractField):
2979         (JSC::FTL::AbstractField::AbstractField):
2980         (JSC::FTL::AbstractField::initialize):
2981         (JSC::FTL::AbstractField::offset):
2982         (IndexedAbstractHeap):
2983         (JSC::FTL::IndexedAbstractHeap::atAnyIndex):
2984         (JSC::FTL::IndexedAbstractHeap::at):
2985         (JSC::FTL::IndexedAbstractHeap::operator[]):
2986         (JSC::FTL::IndexedAbstractHeap::returnInitialized):
2987         (JSC::FTL::IndexedAbstractHeap::MyHashTraits::constructDeletedValue):
2988         (JSC::FTL::IndexedAbstractHeap::MyHashTraits::isDeletedValue):
2989         (NumberedAbstractHeap):
2990         (JSC::FTL::NumberedAbstractHeap::atAnyNumber):
2991         (JSC::FTL::NumberedAbstractHeap::at):
2992         (JSC::FTL::NumberedAbstractHeap::operator[]):
2993         (AbsoluteAbstractHeap):
2994         (JSC::FTL::AbsoluteAbstractHeap::atAnyAddress):
2995         (JSC::FTL::AbsoluteAbstractHeap::at):
2996         (JSC::FTL::AbsoluteAbstractHeap::operator[]):
2997         * ftl/FTLAbstractHeapRepository.cpp: Added.
2998         (FTL):
2999         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
3000         (JSC::FTL::AbstractHeapRepository::~AbstractHeapRepository):
3001         * ftl/FTLAbstractHeapRepository.h: Added.
3002         (FTL):
3003         (AbstractHeapRepository):
3004         * ftl/FTLLowerDFGToLLVM.cpp:
3005         (JSC::FTL::LowerDFGToLLVM::lower):
3006         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
3007         (JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
3008         (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
3009         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
3010         (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
3011         (JSC::FTL::LowerDFGToLLVM::speculateObject):
3012         (JSC::FTL::LowerDFGToLLVM::addressFor):
3013         (JSC::FTL::LowerDFGToLLVM::payloadFor):
3014         (JSC::FTL::LowerDFGToLLVM::tagFor):
3015         (LowerDFGToLLVM):
3016         * ftl/FTLOutput.h:
3017         (FTL):
3018         (JSC::FTL::Output::Output):
3019         (JSC::FTL::Output::initialize):
3020         (JSC::FTL::Output::set):
3021         (JSC::FTL::Output::load):
3022         (JSC::FTL::Output::store):
3023         (Output):
3024         (JSC::FTL::Output::load32):
3025         (JSC::FTL::Output::load64):
3026         (JSC::FTL::Output::loadPtr):
3027         (JSC::FTL::Output::store32):
3028         (JSC::FTL::Output::store64):
3029         (JSC::FTL::Output::storePtr):
3030         (JSC::FTL::Output::addPtr):
3031         (JSC::FTL::Output::address):
3032         (JSC::FTL::Output::baseIndex):
3033         * ftl/FTLTypedPointer.h: Added.
3034         (FTL):
3035         (TypedPointer):
3036         (JSC::FTL::TypedPointer::TypedPointer):
3037         (JSC::FTL::TypedPointer::operator!):
3038         (JSC::FTL::TypedPointer::heap):
3039         (JSC::FTL::TypedPointer::value):
3040         * runtime/Options.h:
3041         (JSC):
3042
3043 2013-03-30  Filip Pizlo  <fpizlo@apple.com>
3044
3045         fourthTier: FTL JIT should be able to compile the Array.prototype.findGraphNode function in Kraken/ai-astar
3046         https://bugs.webkit.org/show_bug.cgi?id=113646
3047
3048         Reviewed by Oliver Hunt.
3049         
3050         This adds enough FTL support to compile Array.prototype.findGraphNode. This isn't
3051         a speed-up, yet, because findGraphNode tends to be aggressively inlined by the DFG,
3052         and the FTL can't yet compile the things into which it was inlined. In future
3053         patches we will get to a point where we can compile the callers, and then we'll be
3054         able to see what the performance effects are.
3055         
3056         But the interesting thing is that it isn't a slow-down, either. This implies that
3057         even if we FTL compile a CodeBlock that we shouldn't have (the fact that we
3058         compiling things that end up being inlined is dumb, and the fact that the current
3059         FTL tiering strategy launches LLVM for those things is even dumber), we still run
3060         at OK performance.
3061
3062         * ftl/FTLCapabilities.cpp:
3063         (JSC::FTL::canCompile):
3064         * ftl/FTLLowerDFGToLLVM.cpp:
3065         (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
3066         (JSC::FTL::LowerDFGToLLVM::compileNode):
3067         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
3068         (LowerDFGToLLVM):
3069         (JSC::FTL::LowerDFGToLLVM::compileGetButterfly):
3070         (JSC::FTL::LowerDFGToLLVM::compileGetArrayLength):
3071         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
3072         (JSC::FTL::LowerDFGToLLVM::compileGetByOffset):
3073         (JSC::FTL::LowerDFGToLLVM::compileCompareEq):
3074         (JSC::FTL::LowerDFGToLLVM::lowInt32):
3075         (JSC::FTL::LowerDFGToLLVM::lowCell):
3076         (JSC::FTL::LowerDFGToLLVM::lowObject):
3077         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
3078         (JSC::FTL::LowerDFGToLLVM::lowJSValue):
3079         (JSC::FTL::LowerDFGToLLVM::lowStorage):
3080         (JSC::FTL::LowerDFGToLLVM::isNotInt32):
3081         (JSC::FTL::LowerDFGToLLVM::isNotCell):
3082         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
3083         (JSC::FTL::LowerDFGToLLVM::speculate):
3084         (JSC::FTL::LowerDFGToLLVM::speculateCell):
3085         (JSC::FTL::LowerDFGToLLVM::speculateObject):
3086         (JSC::FTL::LowerDFGToLLVM::accountedPointer):
3087         (JSC::FTL::LowerDFGToLLVM::weakPointer):
3088         * ftl/FTLOutput.h:
3089         (JSC::FTL::Output::Output):
3090         (JSC::FTL::Output::insertNewBlocksBefore):
3091         (JSC::FTL::Output::appendTo):
3092         (Output):
3093         (JSC::FTL::Output::baseIndex):
3094
3095 2013-03-29  Filip Pizlo  <fpizlo@apple.com>
3096
3097         fourthTier: FTL JIT should be able to compile the Marsaglia random number generator
3098         https://bugs.webkit.org/show_bug.cgi?id=113635
3099
3100         Reviewed by Oliver Hunt.
3101         
3102         Just adding missing functionality.
3103         
3104         Also "fixed" OSR exit to use a call to abort() in addition to using Unreachable
3105         since the latter doesn't actually mean trap - quite the opposite, it tells LLVM
3106         that the code can never be reached.
3107         
3108         The Marsaglia function runs ~60% faster with FTL, than DFG. Not a terrible start.
3109
3110         * JavaScriptCore.xcodeproj/project.pbxproj:
3111         * ftl/FTLAbbreviations.h:
3112         (FTL):
3113         (JSC::FTL::voidType):
3114         (JSC::FTL::structType):
3115         (JSC::FTL::functionType):
3116         (JSC::FTL::addFunction):
3117         (JSC::FTL::setLinkage):
3118         (JSC::FTL::setFunctionCallingConv):
3119         (JSC::FTL::addExternFunction):
3120         (JSC::FTL::constIntToPtr):
3121         (JSC::FTL::constBitCast):
3122         (JSC::FTL::buildMul):
3123         (JSC::FTL::buildOr):
3124         (JSC::FTL::buildShl):
3125         (JSC::FTL::buildAShr):
3126         (JSC::FTL::buildCall):
3127         (JSC::FTL::buildExtractValue):
3128         (JSC::FTL::dumpModule):
3129         (JSC::FTL::verifyModule):
3130         * ftl/FTLCapabilities.cpp:
3131         (JSC::FTL::canCompile):
3132         * ftl/FTLCompile.cpp:
3133         (JSC::FTL::compile):
3134         * ftl/FTLLowerDFGToLLVM.cpp:
3135         (JSC::FTL::LowerDFGToLLVM::lower):
3136         (JSC::FTL::LowerDFGToLLVM::compileBlock):
3137         (JSC::FTL::LowerDFGToLLVM::compileNode):
3138         (JSC::FTL::LowerDFGToLLVM::compileAdd):
3139         (LowerDFGToLLVM):
3140         (JSC::FTL::LowerDFGToLLVM::compileArithMul):
3141         (JSC::FTL::LowerDFGToLLVM::compileBitAnd):
3142         (JSC::FTL::LowerDFGToLLVM::compileBitOr):
3143         (JSC::FTL::LowerDFGToLLVM::compileBitRShift):
3144         (JSC::FTL::LowerDFGToLLVM::compileBitLShift):
3145         (JSC::FTL::LowerDFGToLLVM::compileCompareLess):
3146         (JSC::FTL::LowerDFGToLLVM::compileBranch):
3147         (JSC::FTL::LowerDFGToLLVM::speculateBackward):
3148         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
3149         * ftl/FTLOutput.h:
3150         (JSC::FTL::Output::Output):
3151         (JSC::FTL::Output::initialize):
3152         (JSC::FTL::Output::appendTo):
3153         (Output):
3154         (JSC::FTL::Output::mul):
3155         (JSC::FTL::Output::bitOr):
3156         (JSC::FTL::Output::shl):
3157         (JSC::FTL::Output::aShr):
3158         (JSC::FTL::Output::addWithOverflow32):
3159         (JSC::FTL::Output::mulWithOverflow32):
3160         (JSC::FTL::Output::extractValue):
3161         (JSC::FTL::Output::call):
3162         (JSC::FTL::Output::addWithOverflow32Function):
3163         (JSC::FTL::Output::mulWithOverflow32Function):
3164         * ftl/FTLState.cpp: Added.
3165         (FTL):
3166         (JSC::FTL::State::dumpState):
3167         * ftl/FTLState.h:
3168         (State):
3169
3170 2013-03-29  Filip Pizlo  <fpizlo@apple.com>
3171
3172         Unreviewed, release mode build fix.
3173
3174         * ftl/FTLLowerDFGToLLVM.cpp:
3175         (JSC::FTL::LowerDFGToLLVM::lowInt32):
3176         (JSC::FTL::LowerDFGToLLVM::lowCell):
3177         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
3178         (JSC::FTL::LowerDFGToLLVM::lowJSValue):
3179
3180 2013-03-29  Filip Pizlo  <fpizlo@apple.com>
3181
3182         fourthTier: Change DO_NOT_INCLUDE_LLVM_CPP_HEADERS to LLVM_DO_NOT_INCLUDE_CPP_HEADERS
3183         https://bugs.webkit.org/show_bug.cgi?id=113634
3184
3185         Reviewed by Dan Bernstein.
3186
3187         * ftl/FTLLLVMHeaders.h:
3188
3189 2013-03-29  Filip Pizlo  <fpizlo@apple.com>
3190
3191         fourthTier: FTL JIT should be able run some simple function
3192         https://bugs.webkit.org/show_bug.cgi?id=113481
3193
3194         Reviewed by Geoffrey Garen.
3195         
3196         I forgot to make a couple of the requested review changes, so I'm making
3197         them now!
3198
3199         * ftl/FTLCompile.cpp:
3200         (JSC::FTL::compile):
3201         * ftl/FTLJITCode.h:
3202
3203 2013-03-29  Filip Pizlo  <fpizlo@apple.com>
3204
3205         fourthTier: FTL JIT should be able run some simple function
3206         https://bugs.webkit.org/show_bug.cgi?id=113481
3207
3208         Reviewed by Geoffrey Garen.
3209         
3210         This is the initial version of the FTL JIT (Fourth Tier LLVM JIT).
3211         It includes a lowering from the DFG IR to LLVM IR (FTL::lowerDFGToLLVM)
3212         and a "backend" step that invokes the LLVM and wraps the resulting
3213         function in a thunk (FTL::compile).
3214         
3215         All LLVM IR building functions are wrapped up into a nicer FTL API.
3216         First they're wrapped in an abbreviated API (FTLAbbreviations.h) and
3217         then again into an object-oriented IR builder (FTLOutput.h).
3218         
3219         This runs things. I don't know how fast it runs things. And I don't
3220         make any claims of stability. The FTL is runtime-disabled by default;
3221         you will enable it by doing --useExperimentalFTL=true. Probably if you
3222         do this, you will run slower, because of the heavy thunking we do, the
3223         fact that we don't have anything resembling a sensible tiering story,
3224         and because we only compile ridiculously tiny functions.
3225             
3226         Finally, this still requires a custom set of LLVM headers to build.
3227         I am working on getting that up-streamed to LLVM, and separately I'll
3228         make sure that we have a build checked into this branch.
3229
3230         * Configurations/JavaScriptCore.xcconfig:
3231         * JavaScriptCore.xcodeproj/project.pbxproj:
3232         * bytecode/Operands.h:
3233         (Operands):
3234         (JSC::Operands::Operands):
3235         * dfg/DFGAbstractState.h:
3236         (JSC::DFG::AbstractState::needsTypeCheck):
3237         (AbstractState):
3238         (JSC::DFG::AbstractState::filterEdgeByUse):
3239         * dfg/DFGDriver.cpp:
3240         (JSC::DFG::compile):
3241         * dfg/DFGSpeculativeJIT.cpp:
3242         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
3243         * dfg/DFGSpeculativeJIT.h:
3244         (JSC::DFG::SpeculativeJIT::needsTypeCheck):
3245         (JSC::DFG::SpeculateDoubleOperand::SpeculateDoubleOperand):
3246         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
3247         (DFG):
3248         * dfg/DFGUseKind.h:
3249         (JSC::DFG::shouldNotHaveTypeCheck):
3250         (DFG):
3251         (JSC::DFG::mayHaveTypeCheck):
3252         (JSC::DFG::isDouble):
3253         (JSC::DFG::isCell):
3254         * ftl: Added.
3255         * ftl/FTLAbbreviations.h: Added.
3256         (FTL):
3257         (JSC::FTL::int1Type):
3258         (JSC::FTL::int32Type):
3259         (JSC::FTL::int64Type):
3260         (JSC::FTL::intPtrType):
3261         (JSC::FTL::pointerType):
3262         (JSC::FTL::getParam):
3263         (JSC::FTL::constInt):
3264         (JSC::FTL::appendBasicBlock):
3265         (JSC::FTL::insertBasicBlock):
3266         (JSC::FTL::buildAlloca):
3267         (JSC::FTL::buildAdd):
3268         (JSC::FTL::buildAnd):
3269         (JSC::FTL::buildXor):
3270         (JSC::FTL::buildLoad):
3271         (JSC::FTL::buildStore):
3272         (JSC::FTL::buildZExt):
3273         (JSC::FTL::buildIntCast):
3274         (JSC::FTL::buildIntToPtr):
3275         (JSC::FTL::buildPtrToInt):
3276         (JSC::FTL::buildICmp):
3277         (JSC::FTL::buildSelect):
3278         (JSC::FTL::buildBr):
3279         (JSC::FTL::buildCondBr):
3280         (JSC::FTL::buildRet):
3281         (JSC::FTL::buildUnreachable):
3282         * ftl/FTLCapabilities.cpp: Added.
3283         (FTL):
3284         (JSC::FTL::canCompile):
3285         * ftl/FTLCapabilities.h: Added.
3286         (FTL):
3287         * ftl/FTLCompile.cpp: Added.
3288         (FTL):
3289         (JSC::FTL::compileEntry):
3290         (JSC::FTL::compile):
3291         * ftl/FTLCompile.h: Added.
3292         (FTL):
3293         * ftl/FTLJITCode.cpp: Added.
3294         (FTL):
3295         (JSC::FTL::JITCode::JITCode):
3296         (JSC::FTL::JITCode::~JITCode):
3297         (JSC::FTL::JITCode::addressForCall):
3298         (JSC::FTL::JITCode::executableAddressAtOffset):
3299         (JSC::FTL::JITCode::dataAddressAtOffset):
3300         (JSC::FTL::JITCode::offsetOf):
3301         (JSC::FTL::JITCode::size):
3302         (JSC::FTL::JITCode::contains):
3303         * ftl/FTLJITCode.h: Added.
3304         (FTL):
3305         (JITCode):
3306         * ftl/FTLLLVMHeaders.h: Added.
3307         * ftl/FTLLowerDFGToLLVM.cpp: Added.
3308         (FTL):
3309         (LowerDFGToLLVM):
3310         (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
3311         (JSC::FTL::LowerDFGToLLVM::lower):
3312         (JSC::FTL::LowerDFGToLLVM::addFlushedLocalOpRoots):
3313         (JSC::FTL::LowerDFGToLLVM::closeOverFlushedLocalOps):
3314         (JSC::FTL::LowerDFGToLLVM::addFlushedLocalOp):
3315         (JSC::FTL::LowerDFGToLLVM::addFlushedLocalEdge):
3316         (JSC::FTL::LowerDFGToLLVM::transferAndCheckArguments):
3317         (JSC::FTL::LowerDFGToLLVM::compileBlock):
3318         (JSC::FTL::LowerDFGToLLVM::compileNode):
3319         (JSC::FTL::LowerDFGToLLVM::compileJSConstant):
3320         (JSC::FTL::LowerDFGToLLVM::compileGetLocal):
3321         (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
3322         (JSC::FTL::LowerDFGToLLVM::compileMovHintAndCheck):
3323         (JSC::FTL::LowerDFGToLLVM::compilePhantom):
3324         (JSC::FTL::LowerDFGToLLVM::compileReturn):
3325         (JSC::FTL::LowerDFGToLLVM::speculateBackward):
3326         (JSC::FTL::LowerDFGToLLVM::speculateForward):
3327         (JSC::FTL::LowerDFGToLLVM::speculate):
3328         (JSC::FTL::LowerDFGToLLVM::terminate):
3329         (JSC::FTL::LowerDFGToLLVM::backwardTypeCheck):
3330         (JSC::FTL::LowerDFGToLLVM::forwardTypeCheck):
3331         (JSC::FTL::LowerDFGToLLVM::typeCheck):
3332         (JSC::FTL::LowerDFGToLLVM::lowInt32):
3333         (JSC::FTL::LowerDFGToLLVM::lowCell):
3334         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
3335         (JSC::FTL::LowerDFGToLLVM::lowJSValue):
3336         (JSC::FTL::LowerDFGToLLVM::checkNotInt32):
3337         (JSC::FTL::LowerDFGToLLVM::unboxInt32):
3338         (JSC::FTL::LowerDFGToLLVM::boxInt32):
3339         (JSC::FTL::LowerDFGToLLVM::checkNotCell):
3340         (JSC::FTL::LowerDFGToLLVM::checkNotBoolean):
3341         (JSC::FTL::LowerDFGToLLVM::unboxBoolean):
3342         (JSC::FTL::LowerDFGToLLVM::boxBoolean):
3343         (JSC::FTL::LowerDFGToLLVM::speculateInt32):