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

Aiden Grossman via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 19 00:59:57 PST 2024


================
@@ -1638,18 +1691,24 @@ disassembleObject(ObjectFile &Obj, const ObjectFile &DbgObj,
   LLVM_DEBUG(LVP.dump());
 
   std::unordered_map<uint64_t, BBAddrMap> AddrToBBAddrMap;
+  std::unordered_map<uint64_t, PGOAnalysisMap> AddrToPGOAnalysisMap;
   auto ReadBBAddrMap = [&](std::optional<unsigned> SectionIndex =
                                std::nullopt) {
     AddrToBBAddrMap.clear();
     if (const auto *Elf = dyn_cast<ELFObjectFileBase>(&Obj)) {
-      auto BBAddrMapsOrErr = Elf->readBBAddrMap(SectionIndex);
+      std::vector<PGOAnalysisMap> PGOAnalyses;
+      auto BBAddrMapsOrErr = Elf->readBBAddrMap(SectionIndex, &PGOAnalyses);
       if (!BBAddrMapsOrErr) {
         reportWarning(toString(BBAddrMapsOrErr.takeError()), Obj.getFileName());
         return;
       }
-      for (auto &FunctionBBAddrMap : *BBAddrMapsOrErr)
-        AddrToBBAddrMap.emplace(FunctionBBAddrMap.Addr,
-                                std::move(FunctionBBAddrMap));
+      for (auto &&[FunctionBBAddrMap, FunctionPGOAnalysis] :
----------------
boomanaiden154 wrote:

It was suggested above by @red1bluelost. Not entirely sure what the reasoning was. Using a lvalue reference does create a temporary object here, but I don't think that should matter? The temporary object does prevent the creation of a non-const lvalue reference though, and I wouldn't really consider this to be a const use of the values  from the iterator.

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


More information about the llvm-commits mailing list