[PATCH] D92621: [SampleFDO] [SampleFDO] Store fixed length MD5 in NameTable instead of using ULEB128 if MD5 is used.

[Wei Mi via Phabricator via llvm-commits]

wmi created this revision.
wmi added reviewers: davidxl, wenlei, hoyFB.
Herald added a subscriber: hiraditya.
wmi requested review of this revision.
Herald added a project: LLVM.

Currently during sample profile loading, NameTable has to be loaded entirely up front before any name string is retrieved. That is because NameTable is stored using ULEB128 encoding and cannot be directly accessed like an array. However, if MD5 is used to represent name in the NameTable, it has fixed length. If MD5 names are stored in uint64_t type instead of ULEB128, NameTable can be accessed like an array then in many cases only part of the NameTable has to be read. This is helpful for reducing compile time especially when small source file is compiled.

We find that after this change, the elapsed time to build a large application distributively is reduced by 5% and the accumulative cpu time used for building is also reduced by 5%. The size of the profile is slightly reduced with this change by ~0.2%, and that also indicates encoding MD5 in ULEB128 doesn't save the storage space.


Repository:
  rL LLVM

https://reviews.llvm.org/D92621

Files:
  llvm/include/llvm/ProfileData/SampleProf.h
  llvm/include/llvm/ProfileData/SampleProfReader.h
  llvm/include/llvm/ProfileData/SampleProfWriter.h
  llvm/lib/ProfileData/SampleProfReader.cpp
  llvm/lib/ProfileData/SampleProfWriter.cpp
  llvm/test/Transforms/SampleProfile/Inputs/inline.fixlenmd5.extbinary.afdo
  llvm/test/Transforms/SampleProfile/profile-format.ll
  llvm/test/tools/llvm-profdata/show-prof-info.test

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D92621.309411.patch
Type: text/x-patch
Size: 9259 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20201204/1582a907/attachment-0001.bin>