[all-commits] [llvm/llvm-project] f9403c: Profile matching and IR annotation for memprof pro...

[Teresa Johnson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f9403ca41e5f3dab60cd6e5de26eea65dcab01a4
      https://github.com/llvm/llvm-project/commit/f9403ca41e5f3dab60cd6e5de26eea65dcab01a4
  Author: Teresa Johnson <tejohnson at google.com>
  Date:   2022-09-30 (Fri, 30 Sep 2022)

  Changed paths:
    M llvm/lib/Analysis/MemoryBuiltins.cpp
    M llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp

  Log Message:
  -----------
  Profile matching and IR annotation for memprof profiles.

See also related RFCs:
RFC: Sanitizer-based Heap Profiler [1]
RFC: A binary serialization format for MemProf [2]
RFC: IR metadata format for MemProf [3]*

* Note that the IR metadata format has changed from the RFC during
implementation, as described in the preceeding patch adding the basic
metadata and verification support.

The matching is performed during the normal PGO annotation phase, to
ensure that the inlines applied in the IR at that point are a subset
of the inlines in the profiled binary and thus reflected in the
profile's call stacks. This is important because the call frames are
associated with functions in the profile based on the inlining in the
symbolized call stacks, and this simplifies locating the subset of
profile data relevant for matching onto each function's IR.

The PGOInstrumentationUse pass is enhanced to perform matching for
whatever combination of memprof and regular PGO profile data exists in
the profile.

Using the utilities introduced in D128854:
The memprof profile data for each context is converted to "cold" or
"notcold" based on parameterized thresholds for size, access count, and
lifetime. The memprof allocation contexts are trimmed to the minimal
amount of context required to uniquely identify whether the context is
cold or not cold. For allocations where all profiled contexts have the
same allocation type, no memprof metadata is attached and instead the
allocation call is directly annotated with an attribute specifying the
alloction type. This is the same attributed that will be applied to
allocation calls once cloned for different contexts, and later used
during LibCall simplification to emit allocation hints [4].

Depends on D128141 and D128854.

[1] https://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html
[2] https://lists.llvm.org/pipermail/llvm-dev/2021-September/153007.html
[3] https://discourse.llvm.org/t/rfc-ir-metadata-format-for-memprof/59165
[4] https://github.com/google/tcmalloc/commit/ab87cf382dc56784f783f3aaa43d6d0465d5f385

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


  Commit: 0d7f3464ce0ba3a97df73e08ee0acd4e33adbe9b
      https://github.com/llvm/llvm-project/commit/0d7f3464ce0ba3a97df73e08ee0acd4e33adbe9b
  Author: Teresa Johnson <tejohnson at google.com>
  Date:   2022-09-30 (Fri, 30 Sep 2022)

  Changed paths:
    M llvm/include/llvm/Transforms/Utils/Cloning.h
    M llvm/lib/Analysis/MemoryBuiltins.cpp
    M llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
    M llvm/lib/Transforms/Utils/CloneFunction.cpp
    M llvm/lib/Transforms/Utils/InlineFunction.cpp
    A llvm/test/Transforms/Inline/memprof_inline.ll
    A llvm/test/Transforms/Inline/memprof_inline2.ll

  Log Message:
  -----------
  [MemProf] Update metadata during inlining

Update both memprof and callsite metadata to reflect inlined functions.

For callsite metadata this is simply a concatenation of each cloned
call's call stack with that of the inlined callsite's.

For memprof metadata, each profiled memory info block (MIB) is either
moved to the cloned allocation call or left on the original allocation
call depending on whether its context matches the newly refined call
stack context on the cloned call. We also reapply context trimming
optimizations based on the refined set of contexts on each of the calls
(cloned and original), via utilities in MemoryProfileInfo.

Depends on D128142.

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


Compare: https://github.com/llvm/llvm-project/compare/0d21596c1da5...0d7f3464ce0b