aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/StringRef.cpp
diff options
context:
space:
mode:
authorWilliam Huang <williamjhuang@google.com>2023-05-12 20:40:21 +0000
committerWilliam Huang <williamjhuang@google.com>2023-05-12 20:45:33 +0000
commit4fe91e083a25715880992ea18ae474a3e4dae93f (patch)
treec8a0cc8bc11d3e0f1c6f05476f3cb63554ad8870 /llvm/lib/Support/StringRef.cpp
parentbe5747e516937df6436c9abb8059b6e471c02226 (diff)
downloadllvm-4fe91e083a25715880992ea18ae474a3e4dae93f.zip
llvm-4fe91e083a25715880992ea18ae474a3e4dae93f.tar.gz
llvm-4fe91e083a25715880992ea18ae474a3e4dae93f.tar.bz2
[llvm-profdata] ProfileReader cleanup - preparation for MD5 refactoring - 3
Cleanup profile reader classes to prepare for complex refactoring as propsed in D147740, continuing D148872 This is patch 3/n. This patch changes the behavior of function offset table. Previously when reading ExtBinary profile, the funcOffsetTable (map) is always populated, and in addition if the profile is CS, the orderedFuncOffsets (list) is also populated. However when reading the function samples, only one of the container is being used, never both, so it's a huge waste of time to populate both. Added logic to select which one to use, and completely skip reading function offset table if we are in tool mode (all function samples are to be read sequentially regardless) Reviewed By: davidxl, wenlei Differential Revision: https://reviews.llvm.org/D149124
Diffstat (limited to 'llvm/lib/Support/StringRef.cpp')
0 files changed, 0 insertions, 0 deletions