[llvm] [llvm-objdump] Add support for symbolizing PGOBBAddrMap Info (PR #76386)

Micah Weston via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 8 09:59:27 PST 2024


================
@@ -1264,23 +1264,70 @@ static SymbolInfoTy createDummySymbolInfo(const ObjectFile &Obj,
     return SymbolInfoTy(Addr, Name, Type);
 }
 
-static void
-collectBBAddrMapLabels(const std::unordered_map<uint64_t, BBAddrMap> &AddrToBBAddrMap,
-                       uint64_t SectionAddr, uint64_t Start, uint64_t End,
-                       std::unordered_map<uint64_t, std::vector<std::string>> &Labels) {
+static void collectBBAddrMapLabels(
+    const std::unordered_map<uint64_t, BBAddrMap> &AddrToBBAddrMap,
+    const std::unordered_map<uint64_t, PGOAnalysisMap> &AddrToPGOBBAddrMap,
+    uint64_t SectionAddr, uint64_t Start, uint64_t End,
+    std::unordered_map<
+        uint64_t, std::vector<std::pair<std::string, std::string>>> &Labels) {
   if (AddrToBBAddrMap.empty())
     return;
   Labels.clear();
   uint64_t StartAddress = SectionAddr + Start;
   uint64_t EndAddress = SectionAddr + End;
   auto Iter = AddrToBBAddrMap.find(StartAddress);
+  auto PGOIter = AddrToPGOBBAddrMap.find(StartAddress);
   if (Iter == AddrToBBAddrMap.end())
     return;
-  for (const BBAddrMap::BBEntry &BBEntry : Iter->second.getBBEntries()) {
+  for (size_t I = 0; I < Iter->second.getBBEntries().size(); ++I) {
+    const BBAddrMap::BBEntry &BBEntry = Iter->second.getBBEntries()[I];
     uint64_t BBAddress = BBEntry.Offset + Iter->second.getFunctionAddress();
     if (BBAddress >= EndAddress)
       continue;
-    Labels[BBAddress].push_back(("BB" + Twine(BBEntry.ID)).str());
+
+    std::string LabelString = "BB" + Twine(BBEntry.ID).str();
+    std::string PGOString = "";
+
+    if (!AddrToPGOBBAddrMap.empty()) {
----------------
red1bluelost wrote:

If you end up going with the zip_equal, then this assertion/warning should be unreachable. And if you filter when building the AddrToPGOAnalysisMap then the warning would need to be removed.

I think it should be safe to rely on readBBAddrMap after the fix in #77139. If anything, maybe an assertion should be placed in readBBAddrMap before returning on success but that seems better for a separate PR.

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


More information about the llvm-commits mailing list