[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