[all-commits] [llvm/llvm-project] ef0e0a: [llvm-profdata] Do not create numerical strings fo...

[William Junda Huang via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ef0e0adccd94ffdb10546491ef2719669754d3c9
      https://github.com/llvm/llvm-project/commit/ef0e0adccd94ffdb10546491ef2719669754d3c9
  Author: William Junda Huang <williamjhuang at google.com>
  Date:   2023-10-17 (Tue, 17 Oct 2023)

  Changed paths:
    A llvm/include/llvm/ProfileData/FunctionId.h
    A llvm/include/llvm/ProfileData/HashKeyMap.h
    M llvm/include/llvm/ProfileData/SampleProf.h
    M llvm/include/llvm/ProfileData/SampleProfReader.h
    M llvm/include/llvm/ProfileData/SampleProfWriter.h
    M llvm/include/llvm/Transforms/IPO/ProfiledCallGraph.h
    M llvm/include/llvm/Transforms/IPO/SampleContextTracker.h
    M llvm/lib/ProfileData/SampleProf.cpp
    M llvm/lib/ProfileData/SampleProfReader.cpp
    M llvm/lib/ProfileData/SampleProfWriter.cpp
    M llvm/lib/Target/X86/X86InsertPrefetch.cpp
    M llvm/lib/Transforms/IPO/SampleContextTracker.cpp
    M llvm/lib/Transforms/IPO/SampleProfile.cpp
    M llvm/tools/llvm-profdata/llvm-profdata.cpp
    M llvm/tools/llvm-profgen/CSPreInliner.cpp
    M llvm/tools/llvm-profgen/CSPreInliner.h
    M llvm/tools/llvm-profgen/CallContext.h
    M llvm/tools/llvm-profgen/ProfileGenerator.cpp
    M llvm/tools/llvm-profgen/ProfileGenerator.h
    M llvm/tools/llvm-profgen/ProfiledBinary.cpp
    M llvm/tools/llvm-profgen/ProfiledBinary.h
    M llvm/unittests/ProfileData/SampleProfTest.cpp

  Log Message:
  -----------
  [llvm-profdata] Do not create numerical strings for MD5 function names read from a Sample Profile. (#66164)

This is phase 2 of the MD5 refactoring on Sample Profile following
https://reviews.llvm.org/D147740
    
In previous implementation, when a MD5 Sample Profile is read, the
reader first converts the MD5 values to strings, and then create a
StringRef as if the numerical strings are regular function names, and
later on IPO transformation passes perform string comparison over these
numerical strings for profile matching. This is inefficient since it
causes many small heap allocations.
In this patch I created a class `ProfileFuncRef` that is similar to
`StringRef` but it can represent a hash value directly without any
conversion, and it will be more efficient (I will attach some benchmark
results later) when being used in associative containers.

ProfileFuncRef guarantees the same function name in string form or in
MD5 form has the same hash value, which also fix a few issue in IPO
passes where function matching/lookup only check for function name
string, while returns a no-match if the profile is MD5.

When testing on an internal large profile (> 1 GB, with more than 10
million functions), the full profile load time is reduced from 28 sec to
25 sec in average, and reading function offset table from 0.78s to 0.7s