[all-commits] [llvm/llvm-project] 6bf8f0: [memprof] Add InstrProfWriter::addMemProfData (#11...

[Kazu Hirata via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6bf8f08989420ccd10efed5fac88052ca16e1250
      https://github.com/llvm/llvm-project/commit/6bf8f08989420ccd10efed5fac88052ca16e1250
  Author: Kazu Hirata <kazu at google.com>
  Date:   2024-11-18 (Mon, 18 Nov 2024)

  Changed paths:
    M llvm/include/llvm/ProfileData/InstrProfWriter.h
    M llvm/lib/ProfileData/InstrProfWriter.cpp
    M llvm/unittests/ProfileData/InstrProfTest.cpp

  Log Message:
  -----------
  [memprof] Add InstrProfWriter::addMemProfData (#116528)

This patch adds InstrProfWriter::addMemProfData, which adds the
complete MemProf profile (frames, call stacks, and records) to the
writer context.

Without this function, functions like loadInput in llvm-profdata.cpp
and InstrProfWriter::mergeRecordsFromWriter must add one item (frame,
call stack, or record) at a time.  The new function std::moves the
entire MemProf profile to the writer context if the destination is
empty, which is the common use case.  Otherwise, we fall back to
adding one item at a time behind the scene.

Here are a couple of reasons why we should add this function:

- We've had a bug where we forgot to add one of the three data
  structures (frames, call stacks, and records) to the writer context,
  resulting in a nearly empty indexed profile.  We should always
  package the three data structures together, especially on API
  boundaries.

- We expose a little too much of the MemProf detail to
  InstrProfWriter.  I'd like to gradually transform
  InstrProfReader/Writer to entities managing buffers (sequences of
  bytes), with actual serialization/deserialization left to external
  classes.  We already do some of this in InstrProfReader, where
  InstrProfReader "contracts out" to IndexedMemProfReader to handle
  MemProf details.

I am not changing loadInput or InstrProfWriter::mergeRecordsFromWriter
for now because MemProfReader uses DenseMap for frames and call
stacks, whereas MemProfData uses MapVector.  I'll resolve these
mismatches in subsequent patches.



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