[all-commits] [llvm/llvm-project] 64e768: [SampleFDO] Store fixed length MD5 in NameTable in...

[wmi-11 via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 64e7685368894742517524878716184a8cd3ba9b
      https://github.com/llvm/llvm-project/commit/64e7685368894742517524878716184a8cd3ba9b
  Author: Wei Mi <wmi at google.com>
  Date:   2020-12-08 (Tue, 08 Dec 2020)

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

  Log Message:
  -----------
  [SampleFDO] Store fixed length MD5 in NameTable instead of using ULEB128 if
MD5 is used.

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.

Differential Revision: https://reviews.llvm.org/D92621