The RedirectEdges logic is fragile and not quite complete (doesn't
update in-edges), which adds overhead to maintaining this package.
In my opinion, the post-inlining graph doesn't provide as much value as
the pre-inlining graph. Even the latter I am not convinced should be in
the compiler rather than an external tool, but it is comparatively
easier to maintain.
Drop it for now. Perhaps we'll want it back in the future for tracking
follow-up optimizations, but for now keep things simple.
Change-Id: I3133a2eb97893a14a6770547f96a3f1796798d17
Reviewed-on: https://go-review.googlesource.com/c/go/+/494655
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Actual PGO operation doesn't use these weights at all. They are
theoretically used when printing a dot graph for debugging, but that
doesn't actually work because these weights are always zero.
These fields are initialized by looking for a NodeMap entry with key
{CallerName: sym, CalleeName: "", CallSiteOffset: 0}. These entries will
never exist, as we never put entries in NodeMap without CalleeName.
Since they aren't really used and don't work, just remove them entirely,
which offers nice simplification.
This leaves IRNode with just a single field. I keep the type around as a
future CL will make the *ir.Func optional, allowing nodes with a name
but no IR.
Change-Id: I1646654cad1d0779ce071042768ffad2a7e6ff49
Reviewed-on: https://go-review.googlesource.com/c/go/+/494616
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
We don't use large swaths of this package. Delete the code. We can
always bring it back later if needed.
Change-Id: I6b39a73ed9c48d2d5b37c14763d7bb7956f3ef43
Reviewed-on: https://go-review.googlesource.com/c/go/+/494438
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
graph.go is a simplified fork of github.com/google/pprof/internal/graph,
which is used as an intermediate data structure to construct the final
graph exported by package pgo (IRGraph).
Exporting both is a bit confusing as the former is unused outside of the
package. Since the naming is also similar, move graph.go to its own
package entirely.
Change-Id: I2bccb3ddb6c3f63afb869ea9cf34d2a261cad058
Reviewed-on: https://go-review.googlesource.com/c/go/+/494437
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Work continues on PGO, but the existing support is certainly working.
Change-Id: Ic6724b9b3f174f24662468000d771f7651bb18b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/494435
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Commit-Queue: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Symbol names in the final executable apply escaping to the final
component of a package path (main in example.com becomes
example%2ecom.main).
ir.PkgFuncName does not perform this escaping, meaning we'd fail to
match functions that are escaped in the profile.
Add ir.LinkFuncName which does perform escaping and use it for PGO.
Fixes#59887.
Change-Id: I10634d63d99d0a6fd2f72b929ab35ea227e1336f
Reviewed-on: https://go-review.googlesource.com/c/go/+/490555
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently we fail to print errors from os.Open and profile.Parse of the
PGO profile, losing context useful to understand these errors.
In fixing this, cleanup error use overall to return an error from
pgo.New and report the problematic file at the top level.
Change-Id: Id7e9c781c4b8520eee96b6f5fe8a0b757d947f7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/474995
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
'RedirectEdges' may range over an out-edge slice under modification, leading to out-of-index
panic, and reuse an IREdge object by mistake if there are multiple inlining call-sites.
Fix by rewriting part of the redirecting operation.
Remove 'redirectEdges' as it's not used now and not working as expected in case of multiple
inlining call-sites.
Fixes#58437.
Change-Id: Ic344d4c262df548529acdc9380636cb50835ca51
Reviewed-on: https://go-review.googlesource.com/c/go/+/466915
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
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.
This is a redo of CL 465135, now allowing empty profiles. Note that
preprocessProfileGraph will already cause pgo.New to return nil for
empty profiles.
Fixes#58292
Change-Id: Ia6c94f0793f6ca9b0882b5e2c4d34f38e600c1e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/466675
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts CL 465135.
Reason for revert: This broke cmd/go.TestScript/build_pgo on the linux-amd64-longtest builder: https://build.golang.org/log/8f8ed7bf576f891a06d295c4a5bca987c6e941d6
Change-Id: Ie2f2cc2731099eb28eda6b94dded4dfc34e29441
Reviewed-on: https://go-review.googlesource.com/c/go/+/466439
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
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 is the second round to look for spelling mistakes. This time the
manual sifting of the result list was made easier by filtering out
capitalized and camelcase words.
grep -r --include '*.go' -E '^// .*$' . | aspell list | grep -E -x '[A-Za-z]{1}[a-z]*' | sort | uniq
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Change-Id: Ie8a2092aaa7e1f051aa90f03dbaf2b9aaf5664a9
GitHub-Last-Rev: fc2bd6e0c5
GitHub-Pull-Request: golang/go#57737
Reviewed-on: https://go-review.googlesource.com/c/go/+/461595
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Profiles only began adding Function.start_line in 1.20. If it is
missing, add a hint to the error message that they may need to profile a
build of the application built with a newer version of the toolchain.
Technically profiles are not required to come from Go itself (e.g., they
could be converted from perf), but in practice they most likely are.
Fixes#57674.
Change-Id: I87eca126d3fed0cff94bbb8dd748bd4652f88b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/461195
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Passing a profile with no sample is arguably not a user error.
Accept such a profile, and ignore it as it doesn't indicate any
optimizations. This also makes testing easier.
Change-Id: Iae49a4260e20757419643153f50d8d5d51478411
Reviewed-on: https://go-review.googlesource.com/c/go/+/448495
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently locations are stored in a map and looked up by ID from
the map. The IDs are usually small sequential integers (the Go
pprof CPU profiles are so). Using a slice is more efficient (with
a fallback map to handle weirdly large IDs).
Change-Id: I9e20d5cebca3a5239636413e1bf2f0b273038031
Reviewed-on: https://go-review.googlesource.com/c/go/+/447803
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rather than matching calls to edges in the profile based directly on
line number in the source file, use the line offset from the start of
the function. This makes matching robust to changes in the source file
above the function containing the call.
The start line in the profile comes from Function.start_line, which is
included in Go pprof output since CL 438255.
Currently it is an error if no samples set start_line to help users
detect profiles missing this information. In the future, we should
fallback to using absolute lines, which is better than nothing.
For #55022.
Change-Id: Ie621950cfee1fef8fb200907a2a3f1ded41d04fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/447315
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Currently, with PGO, the inliner uses node weights to decide if a
function is inlineable (with a larger budget). But the actual
inlining is determined by the weight of the call edge. There is a
discrepancy that, if a callee node is hot but the call edge is not,
it would not inlined, and marking the callee inlineable would of
no use.
Instead of using two kinds of weights, we just use the edge
weights to decide inlineability. If a function is the callee of a
hot call edge, its inlineability is determined with a larger
threshold. For a function that exceeds the regular inlining budget,
it is still inlined only when the call edge is hot, as it would
exceed the regular inlining cost for non-hot call sites, even if
it is marked inlineable.
For #55022.
Change-Id: I93fa9919fc6bcbb394e6cfe54ec96a96eede08f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/447015
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The global ListOfHotCallSites set is used to communicate between
CanInline and InlineCalls the set of call sites that InlineCalls may
increase the budget for.
CanInline clears this map on each call, thus assuming that
InlineCalls(x) is called immediately after CanInline(x). This assumption
is false, as CanInline (among other cases) is recursive (CanInline ->
hairyVisitor.doNode -> inlCallee -> CanInline).
When this assumption proves false, we will lose the opportunity to
inline hot calls.
This CL is the least invasive fix for this. ListOfHotCallSites is
actually just a subset of the candHotEdgeMap, with CallSiteInfo.Callee
cleared. candHotEdgeMap doesn't actually need to distinguish based on
Callee, so we can drop callee from candHotEdgeMap as well and just use
that directly [1].
Later CLs should do more work to remove the globals entirely.
For cmd/compile, this inceases the number of PGO inlined functions by
~50% for one set of PGO parameters. I have no evaluated performance
impact.
[1] This is something that we likely want to change in the future.
For #55022.
Change-Id: I57735958d651f6dfa9bd296499841213d20e1706
Reviewed-on: https://go-review.googlesource.com/c/go/+/446755
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Since pgo is a new package, it is reasonably straightforward to
encapsulate its state into a non-global object that we pass around,
which will help keep it isolated.
There are no functional changes in this CL, just packaging up the
globals into a new object.
There are two major pieces of cleanup remaining:
1. reflectdata and noder have separate InlineCalls calls for method
wrappers. The Profile is not plumbed there yet, but this is not a
regression as the globals were previously set only right around the
main inlining pass in gc.Main.
2. pgo.ListOfHotCallSites is still global, as it will require more work
to clean up. It is effectively a local variable in InlinePackage,
except that it assumes that InlineCalls is immediately preceded by a
CanInline call for the same function. This is not necessarily true
due to the recursive nature of CanInline. This also means that some
InlineCalls calls may be missing the list of hot callsites right now.
For #55022.
Change-Id: Ic1fe41f73df96861c65f8bfeecff89862b367290
Reviewed-on: https://go-review.googlesource.com/c/go/+/446303
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Parts of package pgo fetch the line number of a node by parsing the
number out of the string returned from ir.Line().
This is indirect and inefficient, so it should be replaced with a more
direct lookup. It is also potentially buggy: ir.Line uses
ctxt.OutermostPos, i.e., the line number where an inlined node in
inlined. We want ctxt.InnermostPos, because that is the line number used
in pprof profiles that we are matching against (See comments on
OutermostPos and InnermostPos).
I'm not sure whether this was an active, as we use ir.Line before and
during inlining. I think we could see CALL nodes with OutermostPos !=
InnermostPos during midstack inlining, but I am not sure. Regardless,
explicitly using the desired position is clearer.
For #55022.
Change-Id: Ic640761c9e1d01cacbf91f3aaeaf284ad7e38dbd
Reviewed-on: https://go-review.googlesource.com/c/go/+/446302
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
