[PATCH] D112465: [llvm-profgen] Avoid writing any data to CSNameTableSection for the empty CSNameTable

[Wenlei He via Phabricator via llvm-commits]

wenlei added inline comments.


================
Comment at: llvm/lib/ProfileData/SampleProfWriter.cpp:255-256
 std::error_code SampleProfileWriterExtBinaryBase::writeCSNameTableSection() {
+  if (CSNameTable.empty())
+    return sampleprof_error::success;
+
----------------
wlei wrote:
> wenlei wrote:
> > `SampleProfileReaderExtBinaryBase::readCSNameTableSec` would still expect to read a zero here, and if we skip writing the zero, the read will get some garbage data? Or did I miss anything?
> > 
> > Also this is inconsistent with how we write other sections - we don't omit zero size.
> You see the header reader logic below, at the beginning of the loop, it will skip the zero size entry (` if (!Entry.Size)`). so it won't call the `readCSNameTableSec`. Also it has the sanity check after read(`if (Data != SecStart + SecSize)`)
> 
> ```
>   for (auto &Entry : SecHdrTable) {
>     // Skip empty section.
>     if (!Entry.Size)
>       continue;
>    ...
>     if (std::error_code EC = readOneSection(SecStart, SecSize, Entry))
>       return EC;
>     if (Data != SecStart + SecSize)
>       return sampleprof_error::malformed;
>    ....
>    
> ```
> 
> I feel like each section doesn't follow strong encoding convention. `NameTable` is encoded the size probably because it won't have a zero size(if the profile is not empty).
> Like the ProfileSymbolList, it can be a zero section size:
> ```
>   if (ProfSymList && ProfSymList->size() > 0)
>     if (std::error_code EC = ProfSymList->write(*OutputStream))
>       return EC;
> 
>   return sampleprof_error::success;
> ```
> 
> 
> 
> 
> 
Ok, the check on `Entry.Size` explains how it works. But the asymmetry between readCSNameTableSec and writeCSNameTableSection still isn't ideal. One is expecting a size unconditionally, while the other doesn't always write a size. 

The profile symbol list is different in the sense that it never has a size field anyways, so there's no inconsistency.  

I guess practically it works, so if we can't have a better solution, we can do it. If we do this, perhaps add a check to make it explicit that we don't expect zero size on the reader side (SampleProfileReaderExtBinaryBase::readCSNameTableSec).

 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112465/new/

https://reviews.llvm.org/D112465