Source/JavaScriptCore/ChangeLog

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