cmd/compile/internal/pgo: fix hard-coded PGO sample data position

This patch detects at which index position profiling samples that have the value-type samples count are, instead of the previously hard-coded position of index 1. Runtime generated profiles always generate CPU profiling data with the 0 index being CPU nanoseconds, and samples count at index 1, which is why this previously hasn't come up.

Fixes #58292

Change-Id: Idde761d53b02259f3076c4e5dcb4a96a9d53df0e
GitHub-Last-Rev: dabbf9f88c
GitHub-Pull-Request: golang/go#58294
Reviewed-on: https://go-review.googlesource.com/c/go/+/465135
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This commit is contained in:
Frederic Branczyk 2023-02-08 17:59:27 +00:00 committed by Gopher Robot
parent 1a09d57de5
commit cdc65b83fe
2 changed files with 85 additions and 1 deletions

View file

@ -140,9 +140,25 @@ func New(profileFile string) *Profile {
return nil
}
samplesCountIndex := -1
for i, s := range profile.SampleType {
// Samples count is the raw data collected, and CPU nanoseconds is just
// a scaled version of it, so either one we can find is fine.
if (s.Type == "samples" && s.Unit == "count") ||
(s.Type == "cpu" && s.Unit == "nanoseconds") {
samplesCountIndex = i
break
}
}
if samplesCountIndex == -1 {
log.Fatal("failed to find CPU samples count or CPU nanoseconds value-types in profile.")
return nil
}
g := newGraph(profile, &Options{
CallTree: false,
SampleValue: func(v []int64) int64 { return v[1] },
SampleValue: func(v []int64) int64 { return v[samplesCountIndex] },
})
p := &Profile{