Skip to content

[memprof] Avoid repeated hash lookups (NFC) #136268

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

kazutakahirata
Copy link
Contributor

Note that we don't have to worry about CallstackProfileData[Id]
default-constructing the value side of a new map entry. If that
happens, AccessHistogramSize > 0 wouldn't be true, and the new map
entry gets deleted right away.

Note that we don't have to worry about CallstackProfileData[Id]
default-constructing the value side of a new map entry.  If that
happens, AccessHistogramSize > 0 wouldn't be true, and the new map
entry gets deleted right away.
@kazutakahirata kazutakahirata requested a review from nikic April 18, 2025 06:38
@llvmbot llvmbot added the PGO Profile Guided Optimizations label Apr 18, 2025
@llvmbot
Copy link
Member

llvmbot commented Apr 18, 2025

@llvm/pr-subscribers-pgo

Author: Kazu Hirata (kazutakahirata)

Changes

Note that we don't have to worry about CallstackProfileData[Id]
default-constructing the value side of a new map entry. If that
happens, AccessHistogramSize > 0 wouldn't be true, and the new map
entry gets deleted right away.


Full diff: https://github.com/llvm/llvm-project/pull/136268.diff

1 Files Affected:

  • (modified) llvm/lib/ProfileData/MemProfReader.cpp (+6-3)
diff --git a/llvm/lib/ProfileData/MemProfReader.cpp b/llvm/lib/ProfileData/MemProfReader.cpp
index c57f9b22273d4..e0f280b9eb2f6 100644
--- a/llvm/lib/ProfileData/MemProfReader.cpp
+++ b/llvm/lib/ProfileData/MemProfReader.cpp
@@ -600,9 +600,12 @@ Error RawMemProfReader::symbolizeAndFilterStackFrames(
   // Drop the entries where the callstack is empty.
   for (const uint64_t Id : EntriesToErase) {
     StackMap.erase(Id);
-    if (CallstackProfileData[Id].AccessHistogramSize > 0)
-      free((void *)CallstackProfileData[Id].AccessHistogram);
-    CallstackProfileData.erase(Id);
+    if (auto It = CallstackProfileData.find(Id);
+        It != CallstackProfileData.end()) {
+      if (It->second.AccessHistogramSize > 0)
+        free((void *)It->second.AccessHistogram);
+      CallstackProfileData.erase(It);
+    }
   }
 
   if (StackMap.empty())

@kazutakahirata kazutakahirata merged commit 5db95fd into llvm:main Apr 18, 2025
11 of 13 checks passed
@kazutakahirata kazutakahirata deleted the cleanup_001_repeated_hash_lookups_llvm_ProfileData branch April 18, 2025 08:07
@llvm-ci
Copy link
Collaborator

llvm-ci commented Apr 18, 2025

LLVM Buildbot has detected a new failure on builder openmp-s390x-linux running on systemz-1 while building llvm at step 6 "test-openmp".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/88/builds/10618

Here is the relevant piece of the build log for the reference
Step 6 (test-openmp) failure: 1200 seconds without output running [b'ninja', b'-j 4', b'check-openmp'], attempting to kill
...
PASS: ompd-test :: openmp_examples/example_2.c (442 of 452)
PASS: ompd-test :: openmp_examples/example_4.c (443 of 452)
PASS: ompd-test :: openmp_examples/example_5.c (444 of 452)
PASS: ompd-test :: openmp_examples/example_task.c (445 of 452)
UNSUPPORTED: ompd-test :: openmp_examples/ompd_bt.c (446 of 452)
PASS: ompd-test :: openmp_examples/fibonacci.c (447 of 452)
UNSUPPORTED: ompd-test :: openmp_examples/ompd_parallel.c (448 of 452)
PASS: ompd-test :: openmp_examples/parallel.c (449 of 452)
PASS: ompd-test :: openmp_examples/nested.c (450 of 452)
PASS: ompd-test :: openmp_examples/ompd_icvs.c (451 of 452)
command timed out: 1200 seconds without output running [b'ninja', b'-j 4', b'check-openmp'], attempting to kill
process killed by signal 9
program finished with exit code -1
elapsedTime=1382.351288

IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Note that we don't have to worry about CallstackProfileData[Id]
default-constructing the value side of a new map entry.  If that
happens, AccessHistogramSize > 0 wouldn't be true, and the new map
entry gets deleted right away.
IanWood1 pushed a commit to IanWood1/llvm-project that referenced this pull request May 6, 2025
Note that we don't have to worry about CallstackProfileData[Id]
default-constructing the value side of a new map entry.  If that
happens, AccessHistogramSize > 0 wouldn't be true, and the new map
entry gets deleted right away.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PGO Profile Guided Optimizations
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants