Source/JavaScriptCore/ChangeLog

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