2017-11-02 20:54:46 -06:00
|
|
|
// Copyright 2017 The Go Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style
|
|
|
|
// license that can be found in the LICENSE file.
|
|
|
|
|
2018-10-06 00:10:25 -06:00
|
|
|
// Check correctness of various closure corner cases
|
2017-11-02 20:54:46 -06:00
|
|
|
// that are expected to be inlined
|
|
|
|
|
|
|
|
package main
|
|
|
|
|
|
|
|
var ok bool
|
|
|
|
var sink int
|
|
|
|
|
|
|
|
func main() {
|
|
|
|
{
|
|
|
|
if x := func() int { // ERROR "can inline main.func1"
|
|
|
|
return 1
|
|
|
|
}(); x != 1 { // ERROR "inlining call to main.func1"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("x != 1")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
if x := func() int { // ERROR "can inline main.func2" "func literal does not escape"
|
|
|
|
return 1
|
|
|
|
}; x() != 1 { // ERROR "inlining call to main.func2"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("x() != 1")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
if y := func(x int) int { // ERROR "can inline main.func3"
|
|
|
|
return x + 2
|
|
|
|
}(40); y != 42 { // ERROR "inlining call to main.func3"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y != 42")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
if y := func(x int) int { // ERROR "can inline main.func4" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}; y(40) != 42 { // ERROR "inlining call to main.func4"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 42")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func5" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
|
|
|
y = func(x int) int { // ERROR "can inline main.func6" "func literal does not escape"
|
|
|
|
return x + 1
|
|
|
|
}
|
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
func() { // ERROR "func literal does not escape"
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func7.1" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
|
|
|
y = func(x int) int { // ERROR "can inline main.func7.2" "func literal does not escape"
|
|
|
|
return x + 1
|
|
|
|
}
|
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func8" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
|
|
|
y, sink = func(x int) int { // ERROR "can inline main.func9" "func literal does not escape"
|
|
|
|
return x + 1
|
|
|
|
}, 42
|
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
func() { // ERROR "func literal does not escape"
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func10.1" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
|
|
|
y, sink = func(x int) int { // ERROR "can inline main.func10.2" "func literal does not escape"
|
|
|
|
return x + 1
|
|
|
|
}, 42
|
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func11" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
2021-04-11 10:47:13 -06:00
|
|
|
y, sink = func() (func(int) int, int) { // ERROR "can inline main.func12"
|
2021-11-23 06:19:45 -07:00
|
|
|
return func(x int) int { // ERROR "can inline main.func12"
|
2017-11-02 20:54:46 -06:00
|
|
|
return x + 1
|
|
|
|
}, 42
|
2021-11-23 06:19:45 -07:00
|
|
|
}() // ERROR "func literal does not escape" "inlining call to main.func12"
|
2017-11-02 20:54:46 -06:00
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
func() { // ERROR "func literal does not escape"
|
2021-04-11 10:47:13 -06:00
|
|
|
y := func(x int) int { // ERROR "func literal does not escape" "can inline main.func13.1"
|
2017-11-02 20:54:46 -06:00
|
|
|
return x + 2
|
|
|
|
}
|
2021-04-11 10:47:13 -06:00
|
|
|
y, sink = func() (func(int) int, int) { // ERROR "can inline main.func13.2"
|
2021-11-23 06:19:45 -07:00
|
|
|
return func(x int) int { // ERROR "can inline main.func13.2"
|
2017-11-02 20:54:46 -06:00
|
|
|
return x + 1
|
|
|
|
}, 42
|
2021-11-23 06:19:45 -07:00
|
|
|
}() // ERROR "func literal does not escape" "inlining call to main.func13.2"
|
2017-11-02 20:54:46 -06:00
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func14" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
2018-06-06 10:38:35 -06:00
|
|
|
y, ok = map[int]func(int) int{ // ERROR "does not escape"
|
|
|
|
0: func(x int) int { return x + 1 }, // ERROR "can inline main.func15" "func literal escapes"
|
2017-11-02 20:54:46 -06:00
|
|
|
}[0]
|
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
func() { // ERROR "func literal does not escape"
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func16.1" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
2018-06-06 10:38:35 -06:00
|
|
|
y, ok = map[int]func(int) int{ // ERROR "does not escape"
|
2017-11-02 20:54:46 -06:00
|
|
|
0: func(x int) int { return x + 1 }, // ERROR "can inline main.func16.2" "func literal escapes"
|
|
|
|
}[0]
|
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func17" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
2018-06-06 10:38:35 -06:00
|
|
|
y, ok = interface{}(func(x int) int { // ERROR "can inline main.func18" "does not escape"
|
2017-11-02 20:54:46 -06:00
|
|
|
return x + 1
|
2018-06-06 10:38:35 -06:00
|
|
|
}).(func(int) int)
|
2017-11-02 20:54:46 -06:00
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
func() { // ERROR "func literal does not escape"
|
|
|
|
y := func(x int) int { // ERROR "can inline main.func19.1" "func literal does not escape"
|
|
|
|
return x + 2
|
|
|
|
}
|
|
|
|
y, ok = interface{}(func(x int) int { // ERROR "can inline main.func19.2" "does not escape"
|
|
|
|
return x + 1
|
|
|
|
}).(func(int) int)
|
|
|
|
if y(40) != 41 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y(40) != 41")
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
|
|
|
}()
|
|
|
|
}
|
2017-10-21 16:58:37 -06:00
|
|
|
|
|
|
|
{
|
|
|
|
x := 42
|
|
|
|
if y := func() int { // ERROR "can inline main.func20"
|
|
|
|
return x
|
|
|
|
}(); y != 42 { // ERROR "inlining call to main.func20"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y != 42")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
if y := func() int { // ERROR "can inline main.func21" "func literal does not escape"
|
|
|
|
return x
|
|
|
|
}; y() != 42 { // ERROR "inlining call to main.func21"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("y() != 42")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
x := 42
|
2021-04-11 10:47:13 -06:00
|
|
|
if z := func(y int) int { // ERROR "can inline main.func22"
|
|
|
|
return func() int { // ERROR "can inline main.func22.1" "can inline main.func30"
|
2017-10-21 16:58:37 -06:00
|
|
|
return x + y
|
|
|
|
}() // ERROR "inlining call to main.func22.1"
|
2021-04-11 10:47:13 -06:00
|
|
|
}(1); z != 43 { // ERROR "inlining call to main.func22" "inlining call to main.func30"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("z != 43")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
2021-04-11 10:47:13 -06:00
|
|
|
if z := func(y int) int { // ERROR "func literal does not escape" "can inline main.func23"
|
|
|
|
return func() int { // ERROR "can inline main.func23.1" "can inline main.func31"
|
2017-10-21 16:58:37 -06:00
|
|
|
return x + y
|
|
|
|
}() // ERROR "inlining call to main.func23.1"
|
2021-04-11 10:47:13 -06:00
|
|
|
}; z(1) != 43 { // ERROR "inlining call to main.func23" "inlining call to main.func31"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("z(1) != 43")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
a := 1
|
2021-04-11 10:47:13 -06:00
|
|
|
func() { // ERROR "can inline main.func24"
|
|
|
|
func() { // ERROR "can inline main.func24" "can inline main.func32"
|
2017-10-21 16:58:37 -06:00
|
|
|
a = 2
|
2019-04-01 12:58:33 -06:00
|
|
|
}() // ERROR "inlining call to main.func24"
|
2021-04-11 10:47:13 -06:00
|
|
|
}() // ERROR "inlining call to main.func24" "inlining call to main.func32"
|
2017-10-21 16:58:37 -06:00
|
|
|
if a != 2 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("a != 2")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
b := 2
|
|
|
|
func(b int) { // ERROR "func literal does not escape"
|
|
|
|
func() { // ERROR "can inline main.func25.1"
|
|
|
|
b = 3
|
2019-04-01 12:58:33 -06:00
|
|
|
}() // ERROR "inlining call to main.func25.1"
|
2017-10-21 16:58:37 -06:00
|
|
|
if b != 3 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("b != 3")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}(b)
|
|
|
|
if b != 2 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("b != 2")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
c := 3
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
func() { // ERROR "can inline main.func26"
|
2017-10-21 16:58:37 -06:00
|
|
|
c = 4
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
func() {
|
2017-10-21 16:58:37 -06:00
|
|
|
if c != 4 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("c != 4")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
2020-09-21 21:20:00 -06:00
|
|
|
recover() // prevent inlining
|
2017-10-21 16:58:37 -06:00
|
|
|
}()
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
}() // ERROR "inlining call to main.func26" "func literal does not escape"
|
2017-10-21 16:58:37 -06:00
|
|
|
if c != 4 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("c != 4")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
a := 2
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
// This has an unfortunate exponential growth, where as we visit each
|
|
|
|
// function, we inline the inner closure, and that constructs a new
|
|
|
|
// function for any closures inside the inner function, and then we
|
|
|
|
// revisit those. E.g., func34 and func36 are constructed by the inliner.
|
|
|
|
if r := func(x int) int { // ERROR "can inline main.func27"
|
2017-10-21 16:58:37 -06:00
|
|
|
b := 3
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
return func(y int) int { // ERROR "can inline main.func27.1" "can inline main.func34"
|
2017-10-21 16:58:37 -06:00
|
|
|
c := 5
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
return func(z int) int { // ERROR "can inline main.func27.1.1" "can inline main.func27.(func)?2" "can inline main.func34.1" "can inline main.func36"
|
2017-10-21 16:58:37 -06:00
|
|
|
return a*x + b*y + c*z
|
|
|
|
}(10) // ERROR "inlining call to main.func27.1.1"
|
2022-09-30 11:23:48 -06:00
|
|
|
}(100) // ERROR "inlining call to main.func27.1" "inlining call to main.func27.(func)?2"
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
}(1000); r != 2350 { // ERROR "inlining call to main.func27" "inlining call to main.func34" "inlining call to main.func36"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("r != 2350")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
{
|
|
|
|
a := 2
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
if r := func(x int) int { // ERROR "can inline main.func28"
|
2017-10-21 16:58:37 -06:00
|
|
|
b := 3
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
return func(y int) int { // ERROR "can inline main.func28.1" "can inline main.func35"
|
2017-10-21 16:58:37 -06:00
|
|
|
c := 5
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
func(z int) { // ERROR "can inline main.func28.1.1" "can inline main.func28.(func)?2" "can inline main.func35.1" "can inline main.func37"
|
2017-10-21 16:58:37 -06:00
|
|
|
a = a * x
|
|
|
|
b = b * y
|
|
|
|
c = c * z
|
2019-04-01 12:58:33 -06:00
|
|
|
}(10) // ERROR "inlining call to main.func28.1.1"
|
2017-10-21 16:58:37 -06:00
|
|
|
return a + c
|
2022-09-30 11:23:48 -06:00
|
|
|
}(100) + b // ERROR "inlining call to main.func28.1" "inlining call to main.func28.(func)?2"
|
cmd/compile: allow more inlining of functions that construct closures
[This is a roll-forward of CL 479095, which was reverted due to a bad
interaction between inlining and escape analysis, then later fixed
fist with an attempt in CL 482355, then again in 484859 .]
Currently, when the inliner is determining if a function is
inlineable, it descends into the bodies of closures constructed by
that function. This has several unfortunate consequences:
- If the closure contains a disallowed operation (e.g., a defer), then
the outer function can't be inlined. It makes sense that the
*closure* can't be inlined in this case, but it doesn't make sense
to punish the function that constructs the closure.
- The hairiness of the closure counts against the inlining budget of
the outer function. Since we currently copy the closure body when
inlining the outer function, this makes sense from the perspective
of export data size and binary size, but ultimately doesn't make
much sense from the perspective of what should be inlineable.
- Since the inliner walks into every closure created by an outer
function in addition to starting a walk at every closure, this adds
an n^2 factor to inlinability analysis.
This CL simply drops this behavior.
In std, this makes 57 more functions inlinable, and disallows inlining
for 10 (due to the basic instability of our bottom-up inlining
approach), for an net increase of 47 inlinable functions (+0.6%).
This will help significantly with the performance of the functions to
be added for #56102, which have a somewhat complicated nesting of
closures with a performance-critical fast path.
The downside of this seems to be a potential increase in export data
and text size, but the practical impact of this seems to be
negligible:
│ before │ after │
│ bytes │ bytes vs base │
Go/binary 15.12Mi ± 0% 15.14Mi ± 0% +0.16% (n=1)
Go/text 5.220Mi ± 0% 5.237Mi ± 0% +0.32% (n=1)
Compile/binary 22.92Mi ± 0% 22.94Mi ± 0% +0.07% (n=1)
Compile/text 8.428Mi ± 0% 8.435Mi ± 0% +0.08% (n=1)
Updates #56102.
Change-Id: I6e938d596992ffb473cf51e7e598f372ce08deb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/484860
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2023-04-04 16:31:46 -06:00
|
|
|
}(1000); r != 2350 { // ERROR "inlining call to main.func28" "inlining call to main.func35" "inlining call to main.func37"
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("r != 2350")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
if a != 2000 {
|
2018-06-06 10:38:35 -06:00
|
|
|
ppanic("a != 2000")
|
2017-10-21 16:58:37 -06:00
|
|
|
}
|
|
|
|
}
|
2017-11-02 20:54:46 -06:00
|
|
|
}
|
2018-06-06 10:38:35 -06:00
|
|
|
|
|
|
|
//go:noinline
|
|
|
|
func ppanic(s string) { // ERROR "leaking param: s"
|
[dev.regabi] cmd/compile: convert OPANIC argument to interface{} during typecheck
Currently, typecheck leaves arguments to OPANIC as their original
type. This CL changes it to insert implicit OCONVIFACE operations to
convert arguments to `interface{}` like how any other function call
would be handled.
No immediate benefits, other than getting to remove a tiny bit of
special-case logic in order.go's handling of OPANICs. Instead, the
generic code path for handling OCONVIFACE is used, if necessary.
Longer term, this should be marginally helpful for #43753, as it
reduces the number of cases where we need values to be addressable for
runtime calls.
However, this does require adding some hacks to appease existing
tests:
1. We need yet another kludge in inline budgeting, to ensure that
reflect.flag.mustBe stays inlinable for cmd/compile/internal/test's
TestIntendedInlining.
2. Since the OCONVIFACE expressions are now being introduced during
typecheck, they're now visible to escape analysis. So expressions like
"panic(1)" are now seen as "panic(interface{}(1))", and escape
analysis warns that the "interface{}(1)" escapes to the heap. These
have always escaped to heap, just now we're accurately reporting about
it.
(Also, unfortunately fmt.go hides implicit conversions by default in
diagnostics messages, so instead of reporting "interface{}(1) escapes
to heap", it actually reports "1 escapes to heap", which is
confusing. However, this confusing messaging also isn't new.)
Change-Id: Icedf60e1d2e464e219441b8d1233a313770272af
Reviewed-on: https://go-review.googlesource.com/c/go/+/284412
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
2021-01-17 17:14:48 -07:00
|
|
|
panic(s) // ERROR "s escapes to heap"
|
2018-06-06 10:38:35 -06:00
|
|
|
}
|