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

[shaw young via llvm-commits]

================
@@ -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:

> With that definition, blocks containing no return calls should not have successors,
I don’t think this is universally true for exceptions. Consider a block that has a return instruction and throws an exception. The BBB representation would report that there are no successors, but in our current construction of the flow CFG, we would not label that as an exit block – the landing pad would be considered a successor and we’d lose out on applying profile inference to that function. However, this new implementation “ignores” landing pads in the identification of exit blocks which increase our scope (the added test reflects this). I took your advice on IsExit and ExitBlockIndicies – those were redundant as you pointed out and sorry about the confusion.

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