[PATCH] D76255: [SampleFDO] Port MD5 name table support to extbinary format.
David Li via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Mar 17 10:44:20 PDT 2020
davidxl added inline comments.
================
Comment at: llvm/include/llvm/ProfileData/SampleProfReader.h:637
+ /// converted from uint64_t data.
+ std::unique_ptr<std::vector<std::string>> MD5Names;
+
----------------
wmi wrote:
> davidxl wrote:
> > What is the use of MD5Names? It seems only used in useMD5() method.
> >
> > Also why does it need to be unique_ptr?
> Profile only contains md5 numbers (type of uint64_t). NameTable contains StringRef to the names (All formats of profile use the same NameTable). When reading profile using md5, to populate the NameTable structure, I need to convert uint64_t number to std::string and then convert it to StringRef, so I need a buffer to save those std::string because StringRef doesn't own any string data. To be a buffer of NameTable, that is the use of MD5Names.
>
> I make it a unique_ptr because for formats not using md5, MD5Names is useless, so I think an empty unique_ptr may have less cost than an empty std::vector in that case.
The type of NameTable is vector<string> not vector<StringRef> right?
================
Comment at: llvm/include/llvm/ProfileData/SampleProfReader.h:664
/// Function name table.
std::vector<std::string> NameTable;
/// The table mapping from function name to the offset of its FunctionSample
----------------
NameTable Decl here
================
Comment at: llvm/lib/ProfileData/SampleProfReader.cpp:733
+ MD5Names->push_back(std::to_string(*FID));
+ NameTable.push_back(MD5Names->back());
+ }
----------------
The string is pushed into MD5Names, and immediately copied to NameTable. Can MD5Names be skipped here?
Repository:
rL LLVM
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D76255/new/
https://reviews.llvm.org/D76255
More information about the llvm-commits
mailing list