[all-commits] [llvm/llvm-project] 242562: [memprof] Print alloc site matches immediately (#1...

[Kazu Hirata via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2425626d803002027cbf71c39df80cb7b56db0fb
      https://github.com/llvm/llvm-project/commit/2425626d803002027cbf71c39df80cb7b56db0fb
  Author: Kazu Hirata <kazu at google.com>
  Date:   2025-06-01 (Sun, 01 Jun 2025)

  Changed paths:
    M llvm/lib/Transforms/Instrumentation/MemProfiler.cpp
    M llvm/test/Transforms/PGOProfile/memprof-dump-matched-alloc-site.ll
    M llvm/test/Transforms/PGOProfile/memprof.ll

  Log Message:
  -----------
  [memprof] Print alloc site matches immediately (#142233)

Without this patch, we buffer alloc site matches in
FullStackIdToAllocMatchInfo and then print them out at the end of
MemProfUsePass.

This practice is problematic when we have multiple matches per alloc
site.  Consider:

  char *f1() { return new char[3]; }
  char *f2() { return f1(); }
  __attribute__((noinline)) char *f3() { return f2(); }

In this example, f1 contains an alloc site, of course, but so do f2
and f3 via inlining.  When something like this happens,
FullStackIdToAllocMatchInfo gets updated multiple times for the same
full stack ID at:

  FullStackIdToAllocMatchInfo[FullStackId] = { ... };

with different InlinedCallStack.size() each time.

This patch changes the behavior by immediately printing out alloc site
matches, potentially printing out multiple matches for the same
FullStackId.  It is up to the consumer of the message to figure out
the length of the longest matches for example.

For the test, this test adjusts an existing one,
memprof-dump-matched-alloc-site.ll.  Specifically, this patch
"restores" the IR and corresponding profile for f2 and f1 so that the
compiler generates a "MemProf notcold" message for each of f1, f2, and
f3.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications