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