[all-commits] [llvm/llvm-project] 8f20ac: [PGO] Don't reference functions unless value profi...

[Reid Kleckner via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8f20ac9595c8b279641dace6f212b8a9673b24e4
      https://github.com/llvm/llvm-project/commit/8f20ac9595c8b279641dace6f212b8a9673b24e4
  Author: Reid Kleckner <rnk at google.com>
  Date:   2021-05-20 (Thu, 20 May 2021)

  Changed paths:
    M clang/lib/CodeGen/CodeGenModule.cpp
    M clang/lib/CodeGen/CodeGenPGO.cpp
    M clang/lib/CodeGen/CodeGenPGO.h
    M compiler-rt/test/profile/instrprof-value-prof-2.c
    M compiler-rt/test/profile/instrprof-value-prof.c
    M llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp

  Log Message:
  -----------
  [PGO] Don't reference functions unless value profiling is enabled

This reduces the size of chrome.dll.pdb built with optimizations,
coverage, and line table info from 4,690,210,816 to 2,181,128,192, which
makes it possible to fit under the 4GB limit.

This change can greatly reduce binary size in coverage builds, which do
not need value profiling. IR PGO builds are unaffected. There is a minor
behavior change for frontend PGO.

PGO and coverage both use InstrProfiling to create profile data with
counters. PGO records the address of each function in the __profd_
global. It is used later to map runtime function pointer values back to
source-level function names. Coverage does not appear to use this
information.

Recording the address of every function with code coverage drastically
increases code size. Consider this program:

  void foo();
  void bar();
  inline void inlineMe(int x) {
    if (x > 0)
      foo();
    else
      bar();
  }
  int getVal();
  int main() { inlineMe(getVal()); }

With code coverage, the InstrProfiling pass runs before inlining, and it
captures the address of inlineMe in the __profd_ global. This greatly
increases code size, because now the compiler can no longer delete
trivial code.

One downside to this approach is that users of frontend PGO must apply
the -mllvm -enable-value-profiling flag globally in TUs that enable PGO.
Otherwise, some inline virtual method addresses may not be recorded and
will not be able to be promoted. My assumption is that this mllvm flag
is not popular, and most frontend PGO users don't enable it.

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