[llvm] [BOLT] Add sink block to flow CFG in profile inference (PR #95047)

shaw young via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 17 13:59:48 PDT 2024


================
@@ -309,23 +309,28 @@ createFlowFunction(const BinaryFunction::BasicBlockOrderType &BlockOrder) {
   FlowFunction Func;
 
   // Add a special "dummy" source so that there is always a unique entry point.
-  // Because of the extra source, for all other blocks in FlowFunction it holds
-  // that Block.Index == BB->getIndex() + 1
   FlowBlock EntryBlock;
   EntryBlock.Index = 0;
   Func.Blocks.push_back(EntryBlock);
 
-  // Create FlowBlock for every basic block in the binary function
+  // Create FlowBlock for every basic block in the binary function.
   for (const BinaryBasicBlock *BB : BlockOrder) {
     Func.Blocks.emplace_back();
     FlowBlock &Block = Func.Blocks.back();
     Block.Index = Func.Blocks.size() - 1;
+    Block.IsExit = BB->successors().empty();
     (void)BB;
     assert(Block.Index == BB->getIndex() + 1 &&
            "incorrectly assigned basic block index");
   }
 
-  // Create FlowJump for each jump between basic blocks in the binary function
+  // Add a special "dummy" sink block so there is always a unique sink.
----------------
shawbyoung wrote:

The case handled by this PR (exit block, e.g. a block that ends with return/tail call, containing an exception throwing function call) is unique to BOLT. The compiler maintains the invariant "Invoke ends the blockā€ while BOLT treats Invokes as regular calls that don't terminate the block, and merges the fallthrough block which might be an exit block. Work should be done to mirror this in BOLT - splitting blocks with exception throwing calls at the call and adding the landing pad as the successor. However, this change would be extensive, and this PR is a relatively speaking minimally invasive change that is functionally equivalent.  

https://github.com/llvm/llvm-project/pull/95047


More information about the llvm-commits mailing list