[llvm] [BOLT][ICP] Propagate parent hash to newly inserted BBs for BAT (PR #171044)
Jinjie Huang via llvm-commits
llvm-commits at lists.llvm.org
Tue Dec 23 00:55:54 PST 2025
Jinjie-Huang wrote:
If we were to directly use `BBHashMap` to look up the hash and index of the containing BB, the implementation would likely look something like this:
```
if ((InOffset & BRANCHENTRY) == 0) {
const bool IsBlock = BBHashMap.isInputBlock(InOffset >> 1);
...
if (IsBlock) {
BBHash =BBHashMap.getBBHash(InOffset >> 1);
BBIndex =BBHashMap.getBBIndex(InOffset >> 1);
} else {
auto It = BBHashMap.upper_bound(InOffset >> 1);
--It;
BBHash =BBHashMap.getBBHash(It->first);
BBIndex =BBHashMap.getBBIndex(It->first);
}
...
}
```
This works for the current ICP scenario, while this lookup strategy would fail if other passes set the InputOffset of inserted BBs to a value outside the range [containingBB, containingBB + 1) (although I assume most cases would fall within this range).
And that's why I suggested standardizing the behavior of all passes that insert BBs: uniformly set the `InputOffset` to match containing BB's `InputOffset` or make sure they are within the range.
> we should be able to look up the containing block using BRANCHENTRY bit. Can you please elaborate why that doesn't work as intended?
Could you please explain more on how to use BRANCHENTRY for lookups? I might lack some context. Guess we would mark these inserted BBs(Identify by checking that it does not exist in the BBHashMap) with BRANCHENTRY directly in `BoltAddressTranslation::writeEntriesForBB()`, causing them to be treated as branches in BAT and thus automatically bypassing the hash and index handling.
https://github.com/llvm/llvm-project/pull/171044
More information about the llvm-commits
mailing list