aboutsummaryrefslogtreecommitdiff
path: root/clang/unittests/Frontend/CompilerInvocationTest.cpp
diff options
context:
space:
mode:
authorWei Mi <wmi@google.com>2020-12-03 12:19:25 -0800
committerWei Mi <wmi@google.com>2020-12-08 16:21:01 -0800
commit64e7685368894742517524878716184a8cd3ba9b (patch)
tree2c08f908527dac1b702a85ddff20848ca33e3c84 /clang/unittests/Frontend/CompilerInvocationTest.cpp
parent18dff28958804efa6205ffaf12fce65a08211ec5 (diff)
downloadllvm-64e7685368894742517524878716184a8cd3ba9b.zip
llvm-64e7685368894742517524878716184a8cd3ba9b.tar.gz
llvm-64e7685368894742517524878716184a8cd3ba9b.tar.bz2
[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
Diffstat (limited to 'clang/unittests/Frontend/CompilerInvocationTest.cpp')
0 files changed, 0 insertions, 0 deletions