1. 02 Dec, 2013 2 commits
    • fpizlo@apple.com's avatar
      Stores to local captured variables should be intercepted · 0309686b
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124883
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Hahnenberg.
              
      Previously, in bytecode, you could assign to a captured variable just as you would
      assign to any other kind of variable. This complicates closure variable constant
      inference because we don't have any place where we can intercept stores to captured
      variables in the LLInt.
              
      This patch institutes a policy that only certain instructions can store to captured
      variables. If you interpret those instructions and you are required to notifyWrite()
      then you need to check if the relevant variable is captured. Those instructions are
      tracked in CodeBlock.cpp's VerifyCapturedDef. The main one is simply op_captured_mov.
      In the future, we'll probably modify those instructions to have a pointer directly to
      the VariableWatchpointSet; but for now we just introduce the captured instructions as
      placeholders.
              
      In order to validate that the placeholders are inserted correctly, this patch improves
      the CodeBlock validation to be able to inspect every def in the bytecode. To do that,
      this patch refactors the liveness analysis' use/def calculator to be reusable; it now
      takes a functor for each use or def.
              
      In the process of refactoring the liveness analysis, I noticed that op_enter was
      claiming to def all callee registers. That's wrong; it only defs the non-temporary
      variables. Making that change revealed preexisting bugs in the liveness analysis, since
      now the validator would pick up cases where the bytecode claimed to use a temporary and
      the def calculator never noticed the definition (or the converse - where the bytecode
      was actually not using a temporary but the liveness analysis thought that it was a
      use). This patch fixes a few of those bugs.
      
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::stepOverInstruction):
      * bytecode/BytecodeUseDef.h: Added.
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      (JSC::CodeBlock::isCaptured):
      (JSC::CodeBlock::validate):
      * bytecode/CodeBlock.h:
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      (JSC::BytecodeGenerator::resolveCallee):
      (JSC::BytecodeGenerator::emitMove):
      (JSC::BytecodeGenerator::isCaptured):
      (JSC::BytecodeGenerator::local):
      (JSC::BytecodeGenerator::constLocal):
      (JSC::BytecodeGenerator::emitNewFunction):
      (JSC::BytecodeGenerator::emitLazyNewFunction):
      (JSC::BytecodeGenerator::emitNewFunctionInternal):
      * bytecompiler/BytecodeGenerator.h:
      (JSC::Local::Local):
      (JSC::Local::isCaptured):
      (JSC::Local::captureMode):
      (JSC::BytecodeGenerator::captureMode):
      (JSC::BytecodeGenerator::emitNode):
      (JSC::BytecodeGenerator::pushOptimisedForIn):
      * bytecompiler/NodesCodegen.cpp:
      (JSC::PostfixNode::emitResolve):
      (JSC::PrefixNode::emitResolve):
      (JSC::ReadModifyResolveNode::emitBytecode):
      (JSC::AssignResolveNode::emitBytecode):
      (JSC::ConstDeclNode::emitCodeSingle):
      (JSC::ForInNode::emitBytecode):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * runtime/SymbolTable.h:
      (JSC::SymbolTable::isCaptured):
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg.
      
      * js/regress/captured-assignments-expected.txt: Added.
      * js/regress/captured-assignments.html: Added.
      * js/regress/script-tests/captured-assignments.js: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159943 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      0309686b
    • fpizlo@apple.com's avatar
      Instead of watchpointing activation allocation, we should watchpoint entry... · a4ea0663
      fpizlo@apple.com authored
      Instead of watchpointing activation allocation, we should watchpoint entry into functions that have captured variables
      https://bugs.webkit.org/show_bug.cgi?id=125052
      
      Reviewed by Mark Hahnenberg.
              
      This makes us watch function entry rather than activation creation. We only incur the
      costs of doing so for functions that have captured variables, and only on the first two
      entries into the function. This means that closure variable constant inference will
      naturally work even for local uses of the captured variable, like:
              
          (function(){
              var blah = 42;
              ... // stuff
              function () { ... blah /* we can fold this to 42 */ }
              ... blah // we can also fold this to 42.
          })();
              
      Previously, only the nested use would have been foldable.
      
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::dumpBytecode):
      * bytecode/Opcode.h:
      (JSC::padOpcodeName):
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::touch):
      (JSC::InlineWatchpointSet::touch):
      * bytecompiler/BytecodeGenerator.cpp:
      (JSC::BytecodeGenerator::BytecodeGenerator):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGCapabilities.cpp:
      (JSC::DFG::capabilityLevel):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::hasSymbolTable):
      * dfg/DFGNodeType.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGWatchpointCollectionPhase.cpp:
      (JSC::DFG::WatchpointCollectionPhase::handle):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      * jit/JIT.cpp:
      (JSC::JIT::privateCompileMainPass):
      * jit/JIT.h:
      * jit/JITOpcodes.cpp:
      (JSC::JIT::emit_op_touch_entry):
      * llint/LowLevelInterpreter.asm:
      * runtime/CommonSlowPaths.cpp:
      (JSC::SLOW_PATH_DECL):
      * runtime/CommonSlowPaths.h:
      * runtime/JSActivation.h:
      (JSC::JSActivation::create):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTable::SymbolTable):
      * runtime/SymbolTable.h:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159942 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      a4ea0663
  2. 27 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      Do bytecode validation as part of testing · 2eb67eca
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124913
      
      Source/JavaScriptCore: 
      
      Reviewed by Oliver Hunt.
              
      Also fix some small bugs in the bytecode liveness analysis that I found by doing
      this validation thingy.
      
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::isValidRegisterForLiveness):
      (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::validate):
      (JSC::CodeBlock::beginValidationDidFail):
      (JSC::CodeBlock::endValidationDidFail):
      * bytecode/CodeBlock.h:
      * runtime/Executable.cpp:
      (JSC::ScriptExecutable::prepareForExecutionImpl):
      * runtime/Options.h:
      
      Source/WTF: 
      
      Reviewed by Oliver Hunt.
      
      * GNUmakefile.list.am:
      * WTF.vcxproj/WTF.vcxproj:
      * WTF.xcodeproj/project.pbxproj:
      * wtf/CMakeLists.txt:
      * wtf/FastBitVector.cpp: Added.
      (WTF::FastBitVector::dump):
      * wtf/FastBitVector.h:
      (WTF::FastBitVector::resize):
      (WTF::FastBitVector::bitCount):
      (WTF::FastBitVector::arrayLength):
      
      Tools: 
      
      Reviewed by Oliver Hunt.
      
      * Scripts/run-jsc-stress-tests:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159825 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      2eb67eca
  3. 18 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      FTL should have an explicit notion of bytecode liveness · 002405c0
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124181
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      This makes FTL OSR exit use bytecode liveness analysis to determine which variables
      to include values for. The decision of how to get the values of variables is based on
      forward propagation of MovHints and SetLocals.
              
      This fixes a bunch of bugs (like https://bugs.webkit.org/show_bug.cgi?id=124138 but
      also others that I noticed when I started writing more targetted tests) and allows us
      to remove some sketchy code.
      
      * CMakeLists.txt:
      * GNUmakefile.list.am:
      * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/BytecodeBasicBlock.h:
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::isValidRegisterForLiveness):
      (JSC::setForOperand):
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      (JSC::stepOverInstruction):
      (JSC::computeLocalLivenessForBytecodeOffset):
      (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
      (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
      (JSC::getLivenessInfo):
      (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
      (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
      * bytecode/BytecodeLivenessAnalysis.h:
      * bytecode/BytecodeLivenessAnalysisInlines.h: Added.
      (JSC::operandIsAlwaysLive):
      (JSC::operandThatIsNotAlwaysLiveIsLive):
      (JSC::operandIsLive):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::captureCount):
      (JSC::CodeBlock::captureStart):
      (JSC::CodeBlock::captureEnd):
      * bytecode/CodeOrigin.cpp:
      (JSC::InlineCallFrame::dumpInContext):
      * bytecode/FullBytecodeLiveness.h: Added.
      (JSC::FullBytecodeLiveness::FullBytecodeLiveness):
      (JSC::FullBytecodeLiveness::getOut):
      (JSC::FullBytecodeLiveness::operandIsLive):
      (JSC::FullBytecodeLiveness::getLiveness):
      * dfg/DFGAvailability.cpp: Added.
      (JSC::DFG::Availability::dump):
      (JSC::DFG::Availability::dumpInContext):
      * dfg/DFGAvailability.h: Added.
      (JSC::DFG::Availability::Availability):
      (JSC::DFG::Availability::unavailable):
      (JSC::DFG::Availability::withFlush):
      (JSC::DFG::Availability::withNode):
      (JSC::DFG::Availability::withUnavailableNode):
      (JSC::DFG::Availability::nodeIsUndecided):
      (JSC::DFG::Availability::nodeIsUnavailable):
      (JSC::DFG::Availability::hasNode):
      (JSC::DFG::Availability::node):
      (JSC::DFG::Availability::flushedAt):
      (JSC::DFG::Availability::operator!):
      (JSC::DFG::Availability::operator==):
      (JSC::DFG::Availability::merge):
      (JSC::DFG::Availability::mergeNodes):
      (JSC::DFG::Availability::unavailableMarker):
      * dfg/DFGBasicBlock.h:
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGDisassembler.cpp:
      (JSC::DFG::Disassembler::Disassembler):
      * dfg/DFGFlushFormat.cpp:
      (WTF::printInternal):
      * dfg/DFGFlushFormat.h:
      (JSC::DFG::resultFor):
      (JSC::DFG::useKindFor):
      (JSC::DFG::dataFormatFor):
      * dfg/DFGFlushedAt.cpp:
      (JSC::DFG::FlushedAt::dump):
      * dfg/DFGFlushedAt.h:
      (JSC::DFG::FlushedAt::FlushedAt):
      (JSC::DFG::FlushedAt::merge):
      * dfg/DFGGraph.cpp:
      (JSC::DFG::Graph::dump):
      (JSC::DFG::Graph::livenessFor):
      (JSC::DFG::Graph::isLiveInBytecode):
      * dfg/DFGGraph.h:
      (JSC::DFG::Graph::baselineCodeBlockFor):
      * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
      (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
      * dfg/DFGOSRAvailabilityAnalysisPhase.h:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * dfg/DFGResurrectionForValidationPhase.cpp: Added.
      (JSC::DFG::ResurrectionForValidationPhase::ResurrectionForValidationPhase):
      (JSC::DFG::ResurrectionForValidationPhase::run):
      (JSC::DFG::performResurrectionForValidation):
      * dfg/DFGResurrectionForValidationPhase.h: Added.
      * dfg/DFGSSAConversionPhase.cpp:
      (JSC::DFG::SSAConversionPhase::run):
      * dfg/DFGValueSource.h:
      (JSC::DFG::ValueSource::forFlushFormat):
      * dfg/DFGVariableAccessData.h:
      * ftl/FTLExitValue.cpp:
      (JSC::FTL::ExitValue::dumpInContext):
      * ftl/FTLInlineCacheSize.cpp:
      (JSC::FTL::sizeOfGetById):
      * ftl/FTLLocation.cpp:
      (JSC::FTL::Location::gpr):
      (JSC::FTL::Location::fpr):
      (JSC::FTL::Location::directGPR):
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::LowerDFGToLLVM):
      (JSC::FTL::LowerDFGToLLVM::compileBlock):
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileSetLocal):
      (JSC::FTL::LowerDFGToLLVM::compileZombieHint):
      (JSC::FTL::LowerDFGToLLVM::compilePutById):
      (JSC::FTL::LowerDFGToLLVM::compileInvalidationPoint):
      (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock):
      (JSC::FTL::LowerDFGToLLVM::appendOSRExit):
      (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall):
      (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
      (JSC::FTL::LowerDFGToLLVM::addExitArgumentForNode):
      (JSC::FTL::LowerDFGToLLVM::observeMovHint):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::alloca):
      * ftl/FTLValueSource.cpp: Removed.
      * ftl/FTLValueSource.h: Removed.
      * llvm/LLVMAPIFunctions.h:
      * runtime/DumpContext.cpp:
      (JSC::DumpContext::DumpContext):
      * runtime/DumpContext.h:
      * runtime/Options.h:
      * runtime/SymbolTable.h:
      (JSC::SharedSymbolTable::captureStart):
      (JSC::SharedSymbolTable::captureEnd):
      (JSC::SharedSymbolTable::captureCount):
      
      Tools: 
      
      Reviewed by Mark Hahnenberg.
      
      * Scripts/run-jsc-stress-tests:
      
      LayoutTests: 
      
      Reviewed by Mark Hahnenberg or Sam Weinig.
              
      I totally added this test after the rest of the patch was r+'d. Under the right tier-up
      modes this triggers one of the bugs that the rest of the patch is trying to avoid.
      
      * js/regress/script-tests/weird-inlining-const-prop.js: Added.
      (foo):
      (bar):
      (fuzz):
      (testImpl):
      (test):
      * js/regress/weird-inlining-const-prop-expected.txt: Added.
      * js/regress/weird-inlining-const-prop.html: Added.
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159394 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      002405c0
  4. 15 Nov, 2013 1 commit
    • oliver@apple.com's avatar
      Make CLoop easier to build, and make it work · 7c1eb76c
      oliver@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124359
      
      Reviewed by Geoffrey Garen.
      
      Source/JavaScriptCore:
      
      Add --cloop to build-jsc, build-webkit and friends.
      
      Also make CLoop build and work again - This meant adding a
      couple of missing ENABLE(DFG_JIT) blocks, and fixing a few
      other references.
      
      * Configurations/FeatureDefines.xcconfig:
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::computeUsesForBytecodeOffset):
      (JSC::computeDefsForBytecodeOffset):
      * bytecode/DFGExitProfile.cpp:
      * dfg/DFGCapabilities.cpp:
      * dfg/DFGCompilationKey.cpp:
      * dfg/DFGCompilationMode.cpp:
      * jit/JITExceptions.cpp:
      (JSC::genericUnwind):
      
      Source/WebCore:
      
      Add cloop configuration info to WebCore FeatureDefines
      so that it's consistent with JSC
      
      * Configurations/FeatureDefines.xcconfig:
      
      Source/WTF:
      
      Make building with the CLoop forcibly enabled manually
      disable the JITs
      
      * wtf/Platform.h:
      
      Tools:
      
      Add --cloop support to forcibly enable to CLoop build
      
      * Scripts/build-jsc:
      * Scripts/build-webkit:
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159321 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      7c1eb76c
  5. 12 Nov, 2013 2 commits
    • fpizlo@apple.com's avatar
      Liveness analysis should take less memory in CodeBlock when it is unused · d0f35b6b
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124225
      
      Reviewed by Mark Hahnenberg.
              
      Basically, I turned CodeBlock::m_livenessAnalysis into a pointer that is null by
      default.
      
      * bytecode/BytecodeLivenessAnalysis.cpp:
      (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
      (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint):
      (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset):
      (JSC::BytecodeLivenessAnalysis::dumpResults):
      (JSC::BytecodeLivenessAnalysis::compute):
      * bytecode/BytecodeLivenessAnalysis.h:
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::livenessAnalysis):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159141 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      d0f35b6b
    • mhahnenberg@apple.com's avatar
      CodeBlocks should be able to determine bytecode liveness · 3811e215
      mhahnenberg@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=118546
      
      Reviewed by Filip Pizlo.
      
      This will simplify some things in the DFG related to OSR exits and determining 
      which bytecode variables are live at which points during execution. It will
      also be useful for making our conservative GC scan more precise. Currently it 
      doesn't properly account for liveness while the DFG is running, so it will be 
      off by default behing a runtime Options flag.
      
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * bytecode/BytecodeBasicBlock.cpp: Added.
      (JSC::isBranch): Used to determine the end of basic blocks.
      (JSC::isUnconditionalBranch): Used to determine when a branch at the end of a 
      basic block can't possibly fall through to the next basic block in program order.
      (JSC::isTerminal): Also used to detect the end of a block.
      (JSC::isThrow):
      (JSC::isJumpTarget): Used to correctly separate basic blocks. Any jump destination 
      must be the head of its own basic block.
      (JSC::linkBlocks): Links two blocks together in a bi-direcitonal fashion.
      (JSC::computeBytecodeBasicBlocks): Creates a set of basic blocks given a particular 
      CodeBlock and links them together.
      * bytecode/BytecodeBasicBlock.h: Added.
      (JSC::BytecodeBasicBlock::isEntryBlock): Entry blocks are a special basic blocks 
      that indicate the beginning of the function.
      (JSC::BytecodeBasicBlock::isExitBlock): Exit blocks are a special basic block that 
      all blocks that exit the function have as a successor. Entry and exit blocks allows 
      the various code paths to be more regular.
      (JSC::BytecodeBasicBlock::leaderBytecodeOffset): The leader bytecode offset is the 
      bytecode offset of the first instruction in the block.
      (JSC::BytecodeBasicBlock::totalBytecodeLength): The total length of all the bytecodes 
      in this block.
      (JSC::BytecodeBasicBlock::bytecodeOffsets): The bytecode offsets in this particular 
      basic block. This Vector allows us to iterate over the bytecodes in reverse order 
      which wouldn't be possible normally since they are of variable size.
      (JSC::BytecodeBasicBlock::addPredecessor): Links a block to a specified predecessor. 
      Only creates one direction of the link.
      (JSC::BytecodeBasicBlock::addSuccessor): Same as addPredecessor, but for successors.
      (JSC::BytecodeBasicBlock::predecessors): Getter for predecessors.
      (JSC::BytecodeBasicBlock::successors): Getter for successors.
      (JSC::BytecodeBasicBlock::in): Getter for the liveness info at the head of the block.
      (JSC::BytecodeBasicBlock::out): Getter for the liveness info at  the tail of the block.
      (JSC::BytecodeBasicBlock::BytecodeBasicBlock):
      (JSC::BytecodeBasicBlock::addBytecodeLength): When creating basic blocks we call 
      this function when we want to add the next bytecode in program order to this block.
      * bytecode/BytecodeLivenessAnalysis.cpp: Added.
      (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
      (JSC::numberOfCapturedVariables): Convenience wrapper. Returns the
      number of captured variables for a particular CodeBlock, or 0 if 
      the CodeBlock has no SymbolTable.
      (JSC::captureStart): Ditto, but for captureStart().
      (JSC::captureEnd): Ditto, but for captureEnd().
      (JSC::isValidRegisterForLiveness): Returns true if the liveness analysis should 
      track the liveness of a particular operand. We ignore constants, arguments, and 
      captured variables. We ignore arguments because they're live for the duration of 
      a function call. We ignore captured variables because we also treat them as live 
      for the duration of the function. This could probably be improved to be more precise, 
      but it didn't seem worth it for now.
      (JSC::setForOperand): Convenience wrapper that sets the bit in the provided bit 
      vector for the provided operand. It handles skipping over captured variables.
      (JSC::computeUsesForBytecodeOffset): Computes which operands are used by a particular bytecode.
      (JSC::computeDefsForBytecodeOffset): Computes which operands are defined by a particular 
      bytecode. Typically this is just the left-most operand.
      (JSC::findBasicBlockWithLeaderOffset): 
      (JSC::findBasicBlockForBytecodeOffset): Scans over basic blocks to find the block 
      which contains a particular bytecode offset.
      (JSC::computeLocalLivenessForBytecodeOffset): Computes block-local liveness from the 
      bottom of the block until a specified bytecode offset is reached. 
      (JSC::computeLocalLivenessForBlock): Computes liveness for the entire block and 
      stores the resulting liveness at the head.
      (JSC::BytecodeLivenessAnalysis::runLivenessFixpoint): Runs backward flow liveness 
      analysis to fixpoint.
      (JSC::BytecodeLivenessAnalysis::getLivenessInfoForNonCapturedVarsAtBytecodeOffset): 
      Slow path to get liveness info for non-captured, non-argument variable.
      (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): 
      (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset): Returns the liveness 
      info for both captured and non-captured vars at a particular bytecode offset.
      (JSC::BytecodeLivenessAnalysis::dumpResults): Dumps the output of the liveness analysis. 
      Controlled by new flag in Options.h/.cpp.
      (JSC::BytecodeLivenessAnalysis::compute): Creates bytecode basic blocks and runs 
      full liveness analysis.
      * bytecode/BytecodeLivenessAnalysis.h: Added.
      (JSC::BytecodeLivenessAnalysis::hasBeenComputed):
      (JSC::BytecodeLivenessAnalysis::computeIfNecessary):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/CodeBlock.h:
      (JSC::CodeBlock::livenessAnalysis):
      * bytecode/PreciseJumpTargets.cpp: Refactored to be able to get the jump targets for 
      a particular bytecode offset for use during bytecode basic block construction.
      (JSC::getJumpTargetsForBytecodeOffset):
      (JSC::computePreciseJumpTargets):
      (JSC::findJumpTargetsForBytecodeOffset):
      * bytecode/PreciseJumpTargets.h:
      * runtime/Options.cpp:
      (JSC::Options::initialize):
      * runtime/Options.h:
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159136 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      3811e215