You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re starting a project to overhaul the inlining optimization pass in the Go compiler, with the goal of having a far more effective inliner in Go 1.22. This issue will track this work. This document motivates this project and outlines our general design goals. More detailed design documents will follow.
This project is being driven by @thanm and @mdempsky, but we would love to have input from the community. Inlining is inherently very heuristic and can be a deep rabbit hole to go down, so I’m sure many of our design decisions will be motivated by pragmatism and trying to ship something better than what we have for Go 1.22, even if it’s not perfect, with the goal of further improving it in later releases.
I would like to discuss the topic of better supporting automatic instrumentation frameworks, because they will be affected by the planned Go inliner improvements. One example is eBPF which allows to access user code and variables by analyzing the stack and CPU registers via uprobes. Uprobes do not require Go code changes and are usually installed on function-level to read parameters and return values. However, this requires to be able to predict if a function might get inlined. Only functions which never get inlined are potential candidates for installing uprobes.
The opentelemetry-go-instrumentation (How it works) framework is one example which uses eBPF to automatically monitor Go applications.
At Dynatrace, we also rely on some functions which might be inlined in the future, for providing detailed insight into Go applications (through an approach different from eBPF).
I'm bringing up this topic, because I think it would be a great opportunity to improve automatic monitoring capabilities of Golang.
In addition to the improvements that @randall77 linked to in Go 1.22, Go 1.23 includes improved stack slot allocation that directly came out of the inlining project. That change is really important for more aggressive inlining, though it happens to lift all boats.
Unfortunately, other than these few changes, our broader plans for the inliner have currently been shelved because of personnel shifts. It's still in the backlog, but we're weighing it against other opportunities (again).
The heuristic changes that can be enabled with the GOEXPERIMENT never produced reliable performance improvements, so they remain off by default, and one of the big next steps here would be to really understand why that is and what can be used from those heuristics, or if we just need a totally different approach to the heuristics.
Reacted by jub0bs, renthraysk, objectref, pymq, Jason Chen, Florian Lehner and Aurélien Rainone
Activity
gopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511565 mentions this issue:
cmd/compile/internal/inline: add call site flag generationgopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511560 mentions this issue:
cmd/compile/internal/ir: export 'reassigned', handle OASOPgopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511559 mentions this issue:
cmd/compile/internal/inline: analyze function return propertiesgopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511555 mentions this issue:
internal/goexperiment: add "InlinerRevamp" experimentgopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511566 mentions this issue:
cmd/compile/internal/inline/inlheur: assign scores to callsitesgopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511564 mentions this issue:
cmd/compile/internal/inline: build call site tablegopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511562 mentions this issue:
cmd/compile: write "properties" to export data for inlinable funcsgopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511557 mentions this issue:
cmd/compile/internal/inline: add framework to compute func "properties"gopherbot commentedon Jul 21, 2023
Change https://go.dev/cl/511561 mentions this issue:
cmd/compile/internal/inline: analyze function param properties33 remaining items
michael-obermueller commentedon Jul 1, 2024
I would like to discuss the topic of better supporting automatic instrumentation frameworks, because they will be affected by the planned Go inliner improvements. One example is eBPF which allows to access user code and variables by analyzing the stack and CPU registers via uprobes. Uprobes do not require Go code changes and are usually installed on function-level to read parameters and return values. However, this requires to be able to predict if a function might get inlined. Only functions which never get inlined are potential candidates for installing uprobes.
The opentelemetry-go-instrumentation (How it works) framework is one example which uses eBPF to automatically monitor Go applications.
At Dynatrace, we also rely on some functions which might be inlined in the future, for providing detailed insight into Go applications (through an approach different from eBPF).
I'm bringing up this topic, because I think it would be a great opportunity to improve automatic monitoring capabilities of Golang.
objectref commentedon Aug 7, 2024
Hi. Is this new inliner included in Go 1.23?
jub0bs commentedon Aug 7, 2024
@objectref No mention of the new inliner in the provisional release notes for 1.23, so I would say no.
objectref commentedon Aug 7, 2024
@jub0bs Pity. But I would love to know the current state of this, it will be such an improvement!
randall77 commentedon Aug 7, 2024
The new inliner went out in 1.22.
Not sure why this issue is still open, maybe because the inliner is never really done.
aclements commentedon Aug 7, 2024
In addition to the improvements that @randall77 linked to in Go 1.22, Go 1.23 includes improved stack slot allocation that directly came out of the inlining project. That change is really important for more aggressive inlining, though it happens to lift all boats.
Unfortunately, other than these few changes, our broader plans for the inliner have currently been shelved because of personnel shifts. It's still in the backlog, but we're weighing it against other opportunities (again).
The heuristic changes that can be enabled with the GOEXPERIMENT never produced reliable performance improvements, so they remain off by default, and one of the big next steps here would be to really understand why that is and what can be used from those heuristics, or if we just need a totally different approach to the heuristics.
unicode/utf8: make DecodeRune{,InString} inlineable
gopherbot commentedon Aug 28, 2025
Change https://go.dev/cl/699675 mentions this issue:
unicode/utf8: make DecodeRune{,InString} inlineableunicode/utf8: make DecodeRune{,InString} inlineable
unicode/utf8: make DecodeRune{,InString} inlineable
unicode/utf8: make DecodeRune{,InString} inlineable
unicode/utf8: make DecodeRune{,InString} inlineable
unicode/utf8: make DecodeRune{,InString} inlineable