1. 08 Jan, 2014 1 commit
  2. 19 Nov, 2013 1 commit
    • fpizlo@apple.com's avatar
      Infer constant global variables · 33961712
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=124464
      
      Source/JavaScriptCore: 
      
      Reviewed by Sam Weinig.
              
      All global variables that are candidates for watchpoint-based constant inference (i.e.
      not 'const' variables) will now have WatchpointSet's associated with them and those
      are used to drive the inference by tracking three states of each variable:
              
      Uninitialized: the variable's value is Undefined and the WatchpointSet state is
          ClearWatchpoint.
              
      Initialized: the variable's value was set to something (could even be explicitly set
          to Undefined) and the WatchpointSet state is IsWatching.
              
      Invalidated: the variable's value was set to something else (could even be the same
          thing as before but the point is that a put operation did execute again) and the
          WatchpointSet is IsInvalidated.
              
      If the compiler tries to compile a GetGlobalVar and the WatchpointSet state is
      IsWatching, then the current value of the variable can be folded in place of the get,
      and a watchpoint on the variable can be registered.
              
      We handle race conditions between the mutator and compiler by mandating that:
              
      - The mutator changes the WatchpointSet state after executing the put.
              
      - There is no opportunity to install code or call functions between when the mutator
        executes a put and changes the WatchpointSet state.
              
      - The compiler checks the WatchpointSet state prior to reading the value.
              
      The concrete algorithm used by the mutator is:
              
          1. Store the new value into the variable.
          --- Execute a store-store fence.
          2. Bump the state (ClearWatchpoing becomes IsWatching, IsWatching becomes
             IsInvalidated); the IsWatching->IsInvalidated transition may end up firing
             watchpoints.
              
      The concrete algorithm that the compiler uses is:
              
          1. Load the state. If it's *not* IsWatching, then give up on constant inference.
          --- Execute a load-load fence.
          2. Load the value of the variable and use that for folding, while also registering
             a DesiredWatchpoint. The various parts of this step can be done in any order.
              
      The desired watchpoint registration will fail if the watchpoint set is already
      invalidated. Now consider the following interesting interleavings:
              
      Uninitialized->M1->M2->C1->C2: Compiler sees IsWatching because of the mutator's store
          operation, and the variable is folded. The fencing ensures that C2 sees the value
          stored in M1 - i.e. we fold on the value that will actually be watchpointed. If
          before the compilation is installed the mutator executes another store then we
          will be sure that it will be a complete sequence of M1+M2 since compilations get
          installed at safepoints and never "in the middle" of a put_to_scope. Hence that
          compilation installation will be invalidated. If the M1+M2 sequence happens after
          the code is installed, then the code will be invalidated by triggering a jettison.
              
      Uninitialized->M1->C1->C2->M2: Compiler sees Uninitialized and will not fold. This is
          a sensible outcome since if the compiler read the variable's value, it would have
          seen Undefined.
              
      Uninitialized->C1->C2->M1->M2: Compiler sees Uninitialized and will not fold.
      Uninitialized->C1->M1->C2->M2: Compiler sees Uninitialized and will not fold.
      Uninitialized->C1->M1->M2->C2: Compiler sees Uninitialized and will not fold.
      Uninitialized->M1->C1->M2->C2: Compiler sees Uninitialized and will not fold.
              
      IsWatched->M1->M2->C1->C2: Compiler sees IsInvalidated and will not fold.
              
      IsWatched->M1->C1->C2->M2: Compiler will fold, but will also register a desired
          watchpoint, and that watchpoint will get invalidated before the code is installed.
              
      IsWatched->M1->C1->M2->C2: As above, will fold but the code will get invalidated.
      IsWatched->C1->C2->M1->M2: As above, will fold but the code will get invalidated.
      IsWatched->C1->M1->C2->M2: As above, will fold but the code will get invalidated.
      IsWatched->C1->M1->M2->C2: As above, will fold but the code will get invalidated.
              
      Note that this kind of reasoning shows why having the mutator first bump the state and
      then store the new value would be wrong. If we had done that (M1 = bump state, M2 =
      execute put) then we could have the following deadly interleavings:
              
      Uninitialized->M1->C1->C2->M2:
      Uninitialized->M1->C1->M2->C2: Mutator bumps the state to IsWatched and then the
          compiler folds Undefined, since M2 hasn't executed yet. Although C2 will set the
          watchpoint, M1 didn't notify it - it mearly initiated watching. M2 then stores a
          value other than Undefined, and you're toast.
              
      You could fix this sort of thing by making the Desired Watchpoints machinery more
      sophisticated, for example having it track the value that was folded; if the global
      variable's value was later found to be different then we could invalidate the
      compilation. You could also fix it by having the compiler also check that the value of
      the variable is not Undefined before folding. While those all sound great, I decided
      to instead just use the right interleaving since that results in less code and feels
      more intuitive.
              
      This is a 0.5% speed-up on SunSpider, mostly due to a 20% speed-up on math-cordic.
      It's a 0.6% slow-down on LongSpider, mostly due to a 25% slow-down on 3d-cube. This is
      because 3d-cube takes global variable assignment slow paths very often. Note that this
      3d-cube slow-down doesn't manifest as much in SunSpider (only 6% there). This patch is
      also a 1.5% speed-up on V8v7 and a 2.8% speed-up on Octane v1, mostly due to deltablue
      (3.7%), richards (4%), and mandreel (26%). This is a 2% speed-up on Kraken, mostly due
      to a 17.5% speed-up on imaging-gaussian-blur. Something that really illustrates the
      slam-dunk-itude of this patch is the wide range of speed-ups on JSRegress. Casual JS
      programming often leads to global-var-based idioms and those variables tend to be
      assigned once, leading to excellent constant folding opportunities in an optimizing
      JIT. This is very evident in the speed-ups on JSRegress.
      
      * assembler/ARM64Assembler.h:
      (JSC::ARM64Assembler::dmbSY):
      * assembler/ARMv7Assembler.h:
      (JSC::ARMv7Assembler::dmbSY):
      * assembler/MacroAssemblerARM64.h:
      (JSC::MacroAssemblerARM64::memfence):
      * assembler/MacroAssemblerARMv7.h:
      (JSC::MacroAssemblerARMv7::load8):
      (JSC::MacroAssemblerARMv7::memfence):
      * assembler/MacroAssemblerX86.h:
      (JSC::MacroAssemblerX86::load8):
      (JSC::MacroAssemblerX86::store8):
      * assembler/MacroAssemblerX86Common.h:
      (JSC::MacroAssemblerX86Common::getUnusedRegister):
      (JSC::MacroAssemblerX86Common::store8):
      (JSC::MacroAssemblerX86Common::memoryFence):
      * assembler/MacroAssemblerX86_64.h:
      (JSC::MacroAssemblerX86_64::load8):
      (JSC::MacroAssemblerX86_64::store8):
      * assembler/X86Assembler.h:
      (JSC::X86Assembler::movb_rm):
      (JSC::X86Assembler::movzbl_mr):
      (JSC::X86Assembler::mfence):
      (JSC::X86Assembler::X86InstructionFormatter::threeByteOp):
      (JSC::X86Assembler::X86InstructionFormatter::oneByteOp8):
      * bytecode/CodeBlock.cpp:
      (JSC::CodeBlock::CodeBlock):
      * bytecode/Watchpoint.cpp:
      (JSC::WatchpointSet::WatchpointSet):
      (JSC::WatchpointSet::add):
      (JSC::WatchpointSet::notifyWriteSlow):
      * bytecode/Watchpoint.h:
      (JSC::WatchpointSet::state):
      (JSC::WatchpointSet::isStillValid):
      (JSC::WatchpointSet::addressOfSetIsNotEmpty):
      * dfg/DFGAbstractInterpreterInlines.h:
      (JSC::DFG::::executeEffects):
      * dfg/DFGByteCodeParser.cpp:
      (JSC::DFG::ByteCodeParser::getJSConstantForValue):
      (JSC::DFG::ByteCodeParser::getJSConstant):
      (JSC::DFG::ByteCodeParser::parseBlock):
      * dfg/DFGClobberize.h:
      (JSC::DFG::clobberize):
      * dfg/DFGFixupPhase.cpp:
      (JSC::DFG::FixupPhase::fixupNode):
      * dfg/DFGNode.h:
      (JSC::DFG::Node::isStronglyProvedConstantIn):
      (JSC::DFG::Node::hasIdentifierNumberForCheck):
      (JSC::DFG::Node::hasRegisterPointer):
      * dfg/DFGNodeFlags.h:
      * dfg/DFGNodeType.h:
      * dfg/DFGOperations.cpp:
      * dfg/DFGOperations.h:
      * dfg/DFGPredictionPropagationPhase.cpp:
      (JSC::DFG::PredictionPropagationPhase::propagate):
      * dfg/DFGSafeToExecute.h:
      (JSC::DFG::safeToExecute):
      * dfg/DFGSpeculativeJIT.cpp:
      (JSC::DFG::SpeculativeJIT::compileNotifyPutGlobalVar):
      * dfg/DFGSpeculativeJIT.h:
      (JSC::DFG::SpeculativeJIT::callOperation):
      * dfg/DFGSpeculativeJIT32_64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * dfg/DFGSpeculativeJIT64.cpp:
      (JSC::DFG::SpeculativeJIT::compile):
      * ftl/FTLAbbreviatedTypes.h:
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::buildFence):
      * ftl/FTLCapabilities.cpp:
      (JSC::FTL::canCompile):
      * ftl/FTLIntrinsicRepository.h:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::compileNode):
      (JSC::FTL::LowerDFGToLLVM::compileNotifyPutGlobalVar):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::fence):
      * jit/JIT.h:
      * jit/JITOperations.h:
      * jit/JITPropertyAccess.cpp:
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      * jit/JITPropertyAccess32_64.cpp:
      (JSC::JIT::emitPutGlobalVar):
      (JSC::JIT::emit_op_put_to_scope):
      (JSC::JIT::emitSlow_op_put_to_scope):
      * llint/LowLevelInterpreter32_64.asm:
      * llint/LowLevelInterpreter64.asm:
      * llvm/LLVMAPIFunctions.h:
      * offlineasm/arm.rb:
      * offlineasm/arm64.rb:
      * offlineasm/cloop.rb:
      * offlineasm/instructions.rb:
      * offlineasm/x86.rb:
      * runtime/JSGlobalObject.cpp:
      (JSC::JSGlobalObject::addGlobalVar):
      (JSC::JSGlobalObject::addFunction):
      * runtime/JSGlobalObject.h:
      (JSC::JSGlobalObject::addVar):
      (JSC::JSGlobalObject::addConst):
      * runtime/JSScope.cpp:
      (JSC::abstractAccess):
      * runtime/JSSymbolTableObject.h:
      (JSC::symbolTablePut):
      (JSC::symbolTablePutWithAttributes):
      * runtime/SymbolTable.cpp:
      (JSC::SymbolTableEntry::couldBeWatched):
      (JSC::SymbolTableEntry::prepareToWatch):
      (JSC::SymbolTableEntry::notifyWriteSlow):
      * runtime/SymbolTable.h:
      
      LayoutTests: 
      
      Reviewed by Sam Weinig.
      
      * js/regress/global-var-const-infer-expected.txt: Added.
      * js/regress/global-var-const-infer-fire-from-opt-expected.txt: Added.
      * js/regress/global-var-const-infer-fire-from-opt.html: Added.
      * js/regress/global-var-const-infer.html: Added.
      * js/regress/script-tests/global-var-const-infer-fire-from-opt.js: Added.
      (foo):
      (setA):
      (setB):
      (check):
      * js/regress/script-tests/global-var-const-infer.js: Added.
      (foo):
      (check):
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@159545 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      33961712
  3. 17 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. 03 Nov, 2013 1 commit
  5. 02 Nov, 2013 2 commits
  6. 16 Oct, 2013 1 commit
  7. 10 Oct, 2013 1 commit
    • fpizlo@apple.com's avatar
      FTL: Soft-link LLVM as a workaround for LLVM's static initializers and exit-time destructors · ef8dbf84
      fpizlo@apple.com authored
      https://bugs.webkit.org/show_bug.cgi?id=122566
      
      Source/JavaScriptCore: 
      
      Reviewed by Mark Rowe.
              
      The JSC project now builds a libllvmForJSC.dylib. If FTL is enabled, this
      gets copied into JavaScriptCore.framework/Versions/A/Libraries. JSC will
      load the dylib by finding it using NSBundle APIs and then doing dlopen().
      That will only happen lazily, when something happens that requires LLVM.
              
      This mostly takes care of LLVM static initialization overhead by deferring
      it until it's really needed.
              
      This takes care of LLVM's exit-time destructors because inside
      libllvmForJSC.dylib, we override __cxa_atexit.
              
      * Configurations/JavaScriptCore.xcconfig:
      * Configurations/LLVMForJSC.xcconfig: Added.
      * JavaScriptCore.xcodeproj/project.pbxproj:
      * dfg/DFGPlan.cpp:
      (JSC::DFG::Plan::compileInThreadImpl):
      * disassembler/LLVMDisassembler.cpp:
      (JSC::tryToDisassembleWithLLVM):
      * ftl/FTLAbbreviatedTypes.h:
      * ftl/FTLAbbreviations.h:
      (JSC::FTL::voidType):
      (JSC::FTL::int1Type):
      (JSC::FTL::int8Type):
      (JSC::FTL::int16Type):
      (JSC::FTL::int32Type):
      (JSC::FTL::int64Type):
      (JSC::FTL::intPtrType):
      (JSC::FTL::floatType):
      (JSC::FTL::doubleType):
      (JSC::FTL::pointerType):
      (JSC::FTL::structType):
      (JSC::FTL::functionType):
      (JSC::FTL::typeOf):
      (JSC::FTL::mdKindID):
      (JSC::FTL::mdString):
      (JSC::FTL::mdNode):
      (JSC::FTL::setMetadata):
      (JSC::FTL::addFunction):
      (JSC::FTL::setLinkage):
      (JSC::FTL::setFunctionCallingConv):
      (JSC::FTL::getParam):
      (JSC::FTL::constInt):
      (JSC::FTL::constReal):
      (JSC::FTL::constIntToPtr):
      (JSC::FTL::constBitCast):
      (JSC::FTL::appendBasicBlock):
      (JSC::FTL::insertBasicBlock):
      (JSC::FTL::buildPhi):
      (JSC::FTL::addIncoming):
      (JSC::FTL::buildAlloca):
      (JSC::FTL::buildAdd):
      (JSC::FTL::buildSub):
      (JSC::FTL::buildMul):
      (JSC::FTL::buildDiv):
      (JSC::FTL::buildRem):
      (JSC::FTL::buildNeg):
      (JSC::FTL::buildFAdd):
      (JSC::FTL::buildFSub):
      (JSC::FTL::buildFMul):
      (JSC::FTL::buildFDiv):
      (JSC::FTL::buildFRem):
      (JSC::FTL::buildFNeg):
      (JSC::FTL::buildAnd):
      (JSC::FTL::buildOr):
      (JSC::FTL::buildXor):
      (JSC::FTL::buildShl):
      (JSC::FTL::buildAShr):
      (JSC::FTL::buildLShr):
      (JSC::FTL::buildNot):
      (JSC::FTL::buildLoad):
      (JSC::FTL::buildStore):
      (JSC::FTL::buildSExt):
      (JSC::FTL::buildZExt):
      (JSC::FTL::buildFPToSI):
      (JSC::FTL::buildFPToUI):
      (JSC::FTL::buildSIToFP):
      (JSC::FTL::buildUIToFP):
      (JSC::FTL::buildIntCast):
      (JSC::FTL::buildFPCast):
      (JSC::FTL::buildIntToPtr):
      (JSC::FTL::buildPtrToInt):
      (JSC::FTL::buildBitCast):
      (JSC::FTL::buildICmp):
      (JSC::FTL::buildFCmp):
      (JSC::FTL::buildCall):
      (JSC::FTL::setTailCall):
      (JSC::FTL::buildExtractValue):
      (JSC::FTL::buildSelect):
      (JSC::FTL::buildBr):
      (JSC::FTL::buildCondBr):
      (JSC::FTL::buildSwitch):
      (JSC::FTL::addCase):
      (JSC::FTL::buildRet):
      (JSC::FTL::buildUnreachable):
      (JSC::FTL::dumpModule):
      (JSC::FTL::verifyModule):
      * ftl/FTLCompile.cpp:
      (JSC::FTL::compile):
      * ftl/FTLFail.cpp:
      (JSC::FTL::fail):
      * ftl/FTLJITCode.h:
      * ftl/FTLJITFinalizer.h:
      * ftl/FTLLink.cpp:
      * ftl/FTLLowerDFGToLLVM.cpp:
      (JSC::FTL::LowerDFGToLLVM::lower):
      * ftl/FTLOutput.cpp:
      (JSC::FTL::Output::Output):
      (JSC::FTL::Output::~Output):
      * ftl/FTLOutput.h:
      (JSC::FTL::Output::appendTo):
      * ftl/FTLState.cpp:
      (JSC::FTL::State::State):
      (JSC::FTL::State::~State):
      * ftl/WebKitLLVMLibraryAnchor.cpp: Removed.
      * jsc.cpp:
      (jscmain):
      * llvm: Added.
      * llvm/InitializeLLVM.cpp: Added.
      (JSC::initializeLLVM):
      * llvm/InitializeLLVM.h: Added.
      * llvm/InitializeLLVMMac.mm: Added.
      (JSC::initializeLLVMImpl):
      * llvm/InitializeLLVMPOSIX.cpp: Added.
      (JSC::initializeLLVMPOSIX):
      * llvm/InitializeLLVMPOSIX.h: Added.
      * llvm/LLVMAPI.cpp: Added.
      * llvm/LLVMAPI.h: Added.
      * llvm/LLVMAPIFunctions.h: Added.
      * llvm/LLVMHeaders.h: Added.
      * llvm/library: Added.
      * llvm/library/LLVMAnchor.cpp: Added.
      * llvm/library/LLVMExports.cpp: Added.
      (initializeAndGetJSCLLVMAPI):
      * llvm/library/LLVMOverrides.cpp: Added.
      (__cxa_atexit):
      * llvm/library/config_llvm.h: Added.
      * runtime/InitializeThreading.cpp:
      (JSC::initializeThreadingOnce):
      * runtime/Options.h:
      
      Source/WTF: 
      
      Reviewed by Mark Rowe.
              
      Remove all LLVM stuff from WTF since to get LLVM you need to soft-link and it's
      entirely the responsibility of JSC to do that.
              
      Also fixed an export goof that I found after fixing the weak thingy script in JSC.
      
      * WTF.xcodeproj/project.pbxproj:
      * wtf/LLVMHeaders.h: Removed.
      * wtf/text/CString.h:
      (WTF::CStringHash::hash):
      
      Tools: 
      
      Reviewed by Mark Rowe.
      
      * Scripts/configure-llvm:
      
      
      
      git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157260 268f45cc-cd09-0410-ab3c-d52691b4dbfc
      ef8dbf84