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"
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
return func ( ) int { // ERROR "can inline main.func22.1" "can inline main.main.func22.func30"
2017-10-21 16:58:37 -06:00
return x + y
} ( ) // ERROR "inlining call to main.func22.1"
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
} ( 1 ) ; z != 43 { // ERROR "inlining call to main.func22" "inlining call to main.main.func22.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"
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
return func ( ) int { // ERROR "can inline main.func23.1" "can inline main.main.func23.func31"
2017-10-21 16:58:37 -06:00
return x + y
} ( ) // ERROR "inlining call to main.func23.1"
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
} ; z ( 1 ) != 43 { // ERROR "inlining call to main.func23" "inlining call to main.main.func23.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"
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
func ( ) { // ERROR "can inline main.func24" "can inline main.main.func24.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"
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
} ( ) // ERROR "inlining call to main.func24" "inlining call to main.main.func24.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
first with an attempt in CL 482355, then again in CL 484859, and then
one more time with CL 492135.]
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)
Change-Id: I5f75fcceb177f05853996b75184a486528eafe96
Reviewed-on: https://go-review.googlesource.com/c/go/+/492017
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@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
first with an attempt in CL 482355, then again in CL 484859, and then
one more time with CL 492135.]
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)
Change-Id: I5f75fcceb177f05853996b75184a486528eafe96
Reviewed-on: https://go-review.googlesource.com/c/go/+/492017
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@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
first with an attempt in CL 482355, then again in CL 484859, and then
one more time with CL 492135.]
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)
Change-Id: I5f75fcceb177f05853996b75184a486528eafe96
Reviewed-on: https://go-review.googlesource.com/c/go/+/492017
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@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
first with an attempt in CL 482355, then again in CL 484859, and then
one more time with CL 492135.]
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)
Change-Id: I5f75fcceb177f05853996b75184a486528eafe96
Reviewed-on: https://go-review.googlesource.com/c/go/+/492017
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@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: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
return func ( y int ) int { // ERROR "can inline main.func27.1" "can inline main.main.func27.func34"
2017-10-21 16:58:37 -06:00
c := 5
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
return func ( z int ) int { // ERROR "can inline main.func27.1.1" "can inline main.main.func27.func34.1" "can inline main.func27.main.func27.1.func2" "can inline main.main.func27.main.main.func27.func34.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"
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
} ( 100 ) // ERROR "inlining call to main.func27.1" "inlining call to main.func27.main.func27.1.func2"
} ( 1000 ) ; r != 2350 { // ERROR "inlining call to main.func27" "inlining call to main.main.func27.func34" "inlining call to main.main.func27.main.main.func27.func34.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
first with an attempt in CL 482355, then again in CL 484859, and then
one more time with CL 492135.]
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)
Change-Id: I5f75fcceb177f05853996b75184a486528eafe96
Reviewed-on: https://go-review.googlesource.com/c/go/+/492017
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@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: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
return func ( y int ) int { // ERROR "can inline main.func28.1" "can inline main.main.func28.func35"
2017-10-21 16:58:37 -06:00
c := 5
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
func ( z int ) { // ERROR "can inline main.func28.1.1" "can inline main.func28.main.func28.1.func2" "can inline main.main.func28.func35.1" "can inline main.main.func28.main.main.func28.func35.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
cmd/compile: incorporate inlined function names into closure naming
In Go 1.17, cmd/compile gained the ability to inline calls to
functions that contain function literals (aka "closures"). This was
implemented by duplicating the function literal body and emitting a
second LSym, because in general it might be optimized better than the
original function literal.
However, the second LSym was named simply as any other function
literal appearing literally in the enclosing function would be named.
E.g., if f has a closure "f.funcX", and f is inlined into g, we would
create "g.funcY" (N.B., X and Y need not be the same.). Users then
have no idea this function originally came from f.
With this CL, the inlined call stack is incorporated into the clone
LSym's name: instead of "g.funcY", it's named "g.f.funcY".
In the future, it seems desirable to arrange for the clone's name to
appear exactly as the original name, so stack traces remain the same
as when -l or -d=inlfuncswithclosures are used. But it's unclear
whether the linker supports that today, or whether any downstream
tooling would be confused by this.
Updates #60324.
Change-Id: Ifad0ccef7e959e72005beeecdfffd872f63982f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/497137
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
2023-05-22 14:25:15 -06:00
} ( 100 ) + b // ERROR "inlining call to main.func28.1" "inlining call to main.func28.main.func28.1.func2"
} ( 1000 ) ; r != 2350 { // ERROR "inlining call to main.func28" "inlining call to main.main.func28.func35" "inlining call to main.main.func28.main.main.func28.func35.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
}