-
fpizlo@apple.com authored
https://bugs.webkit.org/show_bug.cgi?id=122024 Reviewed by Oliver Hunt. The DFG needs to be able to store things at a known offset from frame pointer so that the runtime can read those things. Prior to this patch, the DFG would use the exact offsets that the bytecode asked for, even in the case of inlining, where it would use the callsite stack offset to shift all of the inlined function's variables over just as they would have been if a bytecode interpreter had really made the call. But this won't work once WebKit-LLVM integration is complete. LLVM has no notion of storing things at a fixed offset from the frame pointer. We could try to hack LLVM to do that, but it would seriously complicate LLVM's stack layout. But what we might be able to do is have LLVM tell us (via an addressof intrinsic and a side-channel) where some alloca landed relative to the frame pointer. Hence if the DFG can put all of its flushed variables in a contiguous range that can be expressed to LLVM as a struct that we alloca, then all of this can still work just fine. Previously the flushed variables didn't fit in a contiguous range, but this patch makes them contiguous by allowing the stack layout to be compressed. What this really means is that there is now a distinction between where the DFG saw a variable stored in bytecode and where it will actually store it in the resulting machine code. Henceforth when the DFG says "local" or "virtual register" it means the variable according to bytecode (with the stack offsetting for inlined code as before), but when it says "machine local" or "machine virtual register" it means the actual place where it will store things in the resulting machine code. All of the OSR exit, inlined arguments, captured variables, and various stack unwinding machine now knows about all of this. Note that the DFG's abstract interpretation still uses bytecode variables rather than machine variables. Same for CSE and abstract heaps. This makes sense since it means that we don't have to decide on machine variable allocation just to do those optimizations. The decision of what a local's machine location becomes is deferred to very late in compilation. We only need to assign machine locations to variables that must be stored to the stack. It's now mandatory to run some kind of "stack layout phase" that makes the decision and updates all data structures. So far the way that this is being used is just to compress the DFG stack layout, which is something that we should have done anyway, a long time ago. And the compression isn't even that good - the current StackLayoutPhase just identifies local indices that are unused in machine code and slides all other variables towards zero. This doesn't achieve particularly good compression but it is better than nothing. Note that this phase makes it seem like the bytecode-machine mapping is based on bytecode local indices; for example if bytecode local 4 is mapped to machine local 3 then it always will be. That's true for the current StackLayoutPhase but it _will not_ be true for all possible stack layout phases and it would be incorrect to assume that it should be true. This is why the current data structures have each VariableAccessData hold its own copy of the machine virtual register, and also have each InlineCallFrame report their own machine virtual registers for the various things. The DFG backend is likely to always use the dumb StackLayoutPhase since it is very cheap to run, but the FTL backend is likely to eventually get a better one, where we do some kind of constraint-based coloring: we institute constraints where some VariableAccessData's must have the same indices as some other ones, and also must be right next to some other ones; then we process all VariableAccessData's and attempt to assign them machine locals while preserving those constraints. This could lead to two VariableAccessDatas for the same bytecode local ending up with different machine locals. * CMakeLists.txt: * GNUmakefile.list.am: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::CodeBlock): (JSC::CodeBlock::isCaptured): (JSC::CodeBlock::framePointerOffsetToGetActivationRegisters): (JSC::CodeBlock::machineSlowArguments): * bytecode/CodeBlock.h: (JSC::CodeBlock::hasSlowArguments): * bytecode/CodeOrigin.cpp: (JSC::CodeOrigin::dump): (JSC::InlineCallFrame::calleeForCallFrame): (JSC::InlineCallFrame::dumpInContext): * bytecode/CodeOrigin.h: (JSC::InlineCallFrame::InlineCallFrame): (JSC::InlineCallFrame::calleeConstant): * bytecode/Operands.h: (JSC::Operands::indexForOperand): * dfg/DFGBasicBlock.cpp: (JSC::DFG::BasicBlock::SSAData::SSAData): * dfg/DFGBasicBlock.h: * dfg/DFGByteCodeParser.cpp: (JSC::DFG::ByteCodeParser::ByteCodeParser): (JSC::DFG::ByteCodeParser::get): (JSC::DFG::ByteCodeParser::getLocal): (JSC::DFG::ByteCodeParser::flushDirect): (JSC::DFG::ByteCodeParser::flush): (JSC::DFG::ByteCodeParser::handleInlining): (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry): (JSC::DFG::ByteCodeParser::parse): * dfg/DFGCommon.h: * dfg/DFGCommonData.h: (JSC::DFG::CommonData::CommonData): * dfg/DFGDesiredWriteBarriers.cpp: (JSC::DFG::DesiredWriteBarrier::trigger): * dfg/DFGDesiredWriteBarriers.h: * dfg/DFGFlushLivenessAnalysisPhase.cpp: (JSC::DFG::FlushLivenessAnalysisPhase::run): (JSC::DFG::FlushLivenessAnalysisPhase::process): (JSC::DFG::FlushLivenessAnalysisPhase::reportError): * dfg/DFGFlushedAt.cpp: Added. (JSC::DFG::FlushedAt::dump): (JSC::DFG::FlushedAt::dumpInContext): * dfg/DFGFlushedAt.h: Added. (JSC::DFG::FlushedAt::FlushedAt): (JSC::DFG::FlushedAt::operator!): (JSC::DFG::FlushedAt::format): (JSC::DFG::FlushedAt::virtualRegister): (JSC::DFG::FlushedAt::operator==): (JSC::DFG::FlushedAt::operator!=): * dfg/DFGGraph.cpp: (JSC::DFG::Graph::Graph): (JSC::DFG::Graph::dump): * dfg/DFGGraph.h: (JSC::DFG::Graph::bytecodeRegisterForArgument): (JSC::DFG::Graph::argumentsRegisterFor): (JSC::DFG::Graph::machineArgumentsRegisterFor): (JSC::DFG::Graph::uncheckedArgumentsRegisterFor): (JSC::DFG::Graph::activationRegister): (JSC::DFG::Graph::uncheckedActivationRegister): (JSC::DFG::Graph::machineActivationRegister): (JSC::DFG::Graph::uncheckedMachineActivationRegister): * dfg/DFGJITCompiler.cpp: (JSC::DFG::JITCompiler::link): * dfg/DFGJITCompiler.h: (JSC::DFG::JITCompiler::noticeOSREntry): * dfg/DFGNode.h: (JSC::DFG::Node::convertToGetLocalUnlinked): (JSC::DFG::Node::convertToGetLocal): (JSC::DFG::Node::machineLocal): (JSC::DFG::Node::hasUnlinkedMachineLocal): (JSC::DFG::Node::setUnlinkedMachineLocal): (JSC::DFG::Node::unlinkedMachineLocal): (JSC::DFG::Node::hasInlineStartData): (JSC::DFG::Node::inlineStartData): * dfg/DFGNodeFlags.cpp: (JSC::DFG::dumpNodeFlags): * dfg/DFGOSREntry.cpp: (JSC::DFG::prepareOSREntry): * dfg/DFGOSREntry.h: (JSC::DFG::OSREntryReshuffling::OSREntryReshuffling): * dfg/DFGOSRExitCompiler64.cpp: (JSC::DFG::OSRExitCompiler::compileExit): * dfg/DFGOSRExitCompilerCommon.cpp: (JSC::DFG::reifyInlinedCallFrames): * dfg/DFGOperations.cpp: * dfg/DFGOperations.h: * dfg/DFGPlan.cpp: (JSC::DFG::Plan::compileInThreadImpl): * dfg/DFGScoreBoard.h: (JSC::DFG::ScoreBoard::ScoreBoard): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::compileInlineStart): (JSC::DFG::SpeculativeJIT::compileCurrentBlock): (JSC::DFG::SpeculativeJIT::createOSREntries): (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments): * dfg/DFGSpeculativeJIT.h: (JSC::DFG::SpeculativeJIT::calleeFrameOffset): (JSC::DFG::SpeculativeJIT::callFrameSlot): (JSC::DFG::SpeculativeJIT::argumentSlot): (JSC::DFG::SpeculativeJIT::callFrameTagSlot): (JSC::DFG::SpeculativeJIT::callFramePayloadSlot): (JSC::DFG::SpeculativeJIT::argumentTagSlot): (JSC::DFG::SpeculativeJIT::argumentPayloadSlot): (JSC::DFG::SpeculativeJIT::framePointerOffsetToGetActivationRegisters): (JSC::DFG::SpeculativeJIT::callOperation): (JSC::DFG::SpeculativeJIT::recordSetLocal): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::emitCall): (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGStackLayoutPhase.cpp: Added. (JSC::DFG::StackLayoutPhase::StackLayoutPhase): (JSC::DFG::StackLayoutPhase::run): (JSC::DFG::performStackLayout): * dfg/DFGStackLayoutPhase.h: Added. * dfg/DFGValidate.cpp: (JSC::DFG::Validate::validate): * dfg/DFGVariableAccessData.h: (JSC::DFG::VariableAccessData::machineLocal): (JSC::DFG::VariableAccessData::flushedAt): * dfg/DFGVirtualRegisterAllocationPhase.cpp: (JSC::DFG::VirtualRegisterAllocationPhase::run): * ftl/FTLExitValue.h: (JSC::FTL::ExitValue::inJSStack): (JSC::FTL::ExitValue::inJSStackAsInt32): (JSC::FTL::ExitValue::inJSStackAsInt52): (JSC::FTL::ExitValue::inJSStackAsDouble): (JSC::FTL::ExitValue::virtualRegister): * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::LowerDFGToLLVM::compileGetArgument): (JSC::FTL::LowerDFGToLLVM::compileGetLocal): (JSC::FTL::LowerDFGToLLVM::compileSetLocal): (JSC::FTL::LowerDFGToLLVM::initializeOSRExitStateForBlock): (JSC::FTL::LowerDFGToLLVM::emitOSRExitCall): * ftl/FTLOSRExitCompiler.cpp: (JSC::FTL::compileStub): * ftl/FTLValueSource.cpp: (JSC::FTL::ValueSource::dump): * ftl/FTLValueSource.h: (JSC::FTL::ValueSource::ValueSource): (JSC::FTL::ValueSource::kind): (JSC::FTL::ValueSource::operator!): (JSC::FTL::ValueSource::node): (JSC::FTL::ValueSource::virtualRegister): * interpreter/Interpreter.cpp: (JSC::unwindCallFrame): * interpreter/StackVisitor.cpp: (JSC::StackVisitor::readInlinedFrame): (JSC::StackVisitor::Frame::createArguments): (JSC::StackVisitor::Frame::existingArguments): * interpreter/StackVisitor.h: * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::addressFor): (JSC::AssemblyHelpers::tagFor): (JSC::AssemblyHelpers::payloadFor): (JSC::AssemblyHelpers::offsetOfArgumentsIncludingThis): * runtime/Arguments.cpp: (JSC::Arguments::tearOff): * runtime/Arguments.h: (JSC::Arguments::allocateSlowArguments): (JSC::Arguments::tryDeleteArgument): (JSC::Arguments::isDeletedArgument): (JSC::Arguments::isArgument): (JSC::Arguments::argument): (JSC::Arguments::finishCreation): * runtime/JSActivation.h: (JSC::JSActivation::create): (JSC::JSActivation::JSActivation): * runtime/JSFunction.cpp: (JSC::RetrieveArgumentsFunctor::operator()): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@156984 268f45cc-cd09-0410-ab3c-d52691b4dbfc
a62d4829