Refactor the inliner to simplify block linking
authorrmorisset@apple.com <rmorisset@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 9 Oct 2017 23:55:25 +0000 (23:55 +0000)
committerrmorisset@apple.com <rmorisset@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 9 Oct 2017 23:55:25 +0000 (23:55 +0000)
commitac33b35eefd582d0fa74ae26ba4ce31747b1830d
tree8f89c5cad129a05a1be4aac2ff0a609372881dcb
parenteda04c13d0696b44b18217ef4c92e3a6b9c2fee9
Refactor the inliner to simplify block linking
https://bugs.webkit.org/show_bug.cgi?id=177922

Reviewed by Saam Barati.

The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
- m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
- m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee,
or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked
terminal that needs to be taken off m_unlinkedBlocks.
I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry,
that is the one that holds their target in its m_linkingTargets field.

There are a few much smaller refactors in this patch:
- parse() is now of type void insted of bool (it was always returning true)
- The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
- The 9 argument version was cleaned up and simplified
- I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings
- Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
- Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)

* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::addToGraph):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::refineStatically):
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::handleVarargsCall):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::attemptToInlineCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::parseCodeBlock):
(JSC::DFG::ByteCodeParser::parse):
(JSC::DFG::parse):
(JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
* dfg/DFGByteCodeParser.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@223086 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/dfg/DFGBasicBlock.h
Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp
Source/JavaScriptCore/dfg/DFGByteCodeParser.h
Source/JavaScriptCore/dfg/DFGGraph.cpp
Source/JavaScriptCore/dfg/DFGPlan.cpp