1
0
mirror of https://github.com/golang/go synced 2024-11-06 16:26:10 -07:00
go/test/inline.go

396 lines
11 KiB
Go
Raw Normal View History

// errorcheckwithauto -0 -m -d=inlfuncswithclosures=1
// Copyright 2015 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.
// Test, using compiler diagnostic flags, that inlining is working.
// Compiles but does not run.
package foo
import (
cmd/compile: handle simple inlined calls in staticinit Global variable initializers like var myErr error = &myError{"msg"} have been converted to statically initialized data from the earliest days of Go: there is no init-time execution or allocation for that line of code. But if the expression is moved into an inlinable function, the static initialization no longer happens. That is, this code has always executed and allocated at init time, even after we added inlining to the compiler, which should in theory make this code equivalent to the original: func NewError(s string) error { return &myError{s} } var myErr2 = NewError("msg") This CL makes the static initialization rewriter understand inlined functions consisting of a single return statement, like in this example, so that myErr2 can be implemented as statically initialized data too, just like myErr, with no init-time execution or allocation. A real example of code that benefits from this rewrite is all globally declared errors created with errors.New, like package io var EOF = errors.New("EOF") Package io no longer has to allocate and initialize EOF each time a program starts. Another example of code that benefits is any globally declared godebug setting (using the API from CL 449504), like package http var http2server = godebug.New("http2server") These are no longer allocated and initialized at program startup either. The list of functions that are inlined into static initializers when compiling std and cmd (along with how many times each occurs) is: cmd/compile/internal/ssa.StringToAux (3) cmd/compile/internal/walk.mkmapnames (4) errors.New (360) go/ast.NewIdent (1) go/constant.MakeBool (4) go/constant.MakeInt64 (3) image.NewUniform (4) image/color.ModelFunc (11) internal/godebug.New (12) vendor/golang.org/x/text/unicode/bidi.newBidiTrie (1) vendor/golang.org/x/text/unicode/norm.newNfcTrie (1) vendor/golang.org/x/text/unicode/norm.newNfkcTrie (1) For the cmd/go binary, this CL cuts the number of init-time allocations from about 1920 to about 1620 (a 15% reduction). The total executable code footprint of init functions is reduced by 24kB, from 137kB to 113kB (an 18% reduction). The overall binary size is reduced by 45kB, from 15.335MB to 15.290MB (a 0.3% reduction). (The binary size savings is larger than the executable code savings because every byte of executable code also requires corresponding runtime tables for unwinding, source-line mapping, and so on.) Also merge test/sinit_run.go, which had stopped testing anything at all as of CL 161337 (Feb 2019) and initempty.go into a new test noinit.go. Fixes #30820. Change-Id: I52f7275b1ac2a0a32e22c29f9095071c7b1fac20 Reviewed-on: https://go-review.googlesource.com/c/go/+/450136 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Joedian Reid <joedian@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
2022-11-13 07:22:35 -07:00
"errors"
"runtime"
"unsafe"
)
func add2(p *byte, n uintptr) *byte { // ERROR "can inline add2" "leaking param: p to result"
return (*byte)(add1(unsafe.Pointer(p), n)) // ERROR "inlining call to add1"
}
func add1(p unsafe.Pointer, x uintptr) unsafe.Pointer { // ERROR "can inline add1" "leaking param: p to result"
return unsafe.Pointer(uintptr(p) + x)
}
func f(x *byte) *byte { // ERROR "can inline f" "leaking param: x to result"
return add2(x, 1) // ERROR "inlining call to add2" "inlining call to add1"
}
//go:noinline
func g(x int) int {
return x + 1
}
func h(x int) int { // ERROR "can inline h"
return x + 2
}
func i(x int) int { // ERROR "can inline i"
const y = 2
return x + y
}
func j(x int) int { // ERROR "can inline j"
switch {
case x > 0:
return x + 2
default:
return x + 1
}
}
func f2() int { // ERROR "can inline f2"
tmp1 := h
tmp2 := tmp1
return tmp2(0) // ERROR "inlining call to h"
}
cmd/compile: handle simple inlined calls in staticinit Global variable initializers like var myErr error = &myError{"msg"} have been converted to statically initialized data from the earliest days of Go: there is no init-time execution or allocation for that line of code. But if the expression is moved into an inlinable function, the static initialization no longer happens. That is, this code has always executed and allocated at init time, even after we added inlining to the compiler, which should in theory make this code equivalent to the original: func NewError(s string) error { return &myError{s} } var myErr2 = NewError("msg") This CL makes the static initialization rewriter understand inlined functions consisting of a single return statement, like in this example, so that myErr2 can be implemented as statically initialized data too, just like myErr, with no init-time execution or allocation. A real example of code that benefits from this rewrite is all globally declared errors created with errors.New, like package io var EOF = errors.New("EOF") Package io no longer has to allocate and initialize EOF each time a program starts. Another example of code that benefits is any globally declared godebug setting (using the API from CL 449504), like package http var http2server = godebug.New("http2server") These are no longer allocated and initialized at program startup either. The list of functions that are inlined into static initializers when compiling std and cmd (along with how many times each occurs) is: cmd/compile/internal/ssa.StringToAux (3) cmd/compile/internal/walk.mkmapnames (4) errors.New (360) go/ast.NewIdent (1) go/constant.MakeBool (4) go/constant.MakeInt64 (3) image.NewUniform (4) image/color.ModelFunc (11) internal/godebug.New (12) vendor/golang.org/x/text/unicode/bidi.newBidiTrie (1) vendor/golang.org/x/text/unicode/norm.newNfcTrie (1) vendor/golang.org/x/text/unicode/norm.newNfkcTrie (1) For the cmd/go binary, this CL cuts the number of init-time allocations from about 1920 to about 1620 (a 15% reduction). The total executable code footprint of init functions is reduced by 24kB, from 137kB to 113kB (an 18% reduction). The overall binary size is reduced by 45kB, from 15.335MB to 15.290MB (a 0.3% reduction). (The binary size savings is larger than the executable code savings because every byte of executable code also requires corresponding runtime tables for unwinding, source-line mapping, and so on.) Also merge test/sinit_run.go, which had stopped testing anything at all as of CL 161337 (Feb 2019) and initempty.go into a new test noinit.go. Fixes #30820. Change-Id: I52f7275b1ac2a0a32e22c29f9095071c7b1fac20 Reviewed-on: https://go-review.googlesource.com/c/go/+/450136 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Joedian Reid <joedian@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Russ Cox <rsc@golang.org>
2022-11-13 07:22:35 -07:00
var abc = errors.New("abc") // ERROR "inlining call to errors.New"
var somethingWrong error
// local closures can be inlined
func l(x, y int) (int, int, error) { // ERROR "can inline l"
e := func(err error) (int, int, error) { // ERROR "can inline l.func1" "func literal does not escape" "leaking param: err to result"
return 0, 0, err
}
if x == y {
e(somethingWrong) // ERROR "inlining call to l.func1"
} else {
f := e
f(nil) // ERROR "inlining call to l.func1"
}
return y, x, nil
}
// any re-assignment prevents closure inlining
func m() int {
foo := func() int { return 1 } // ERROR "can inline m.func1" "func literal does not escape"
x := foo()
foo = func() int { return 2 } // ERROR "can inline m.func2" "func literal does not escape"
return x + foo()
}
// address taking prevents closure inlining
func n() int {
foo := func() int { return 1 } // ERROR "can inline n.func1" "func literal does not escape"
bar := &foo
x := (*bar)() + foo()
return x
}
// make sure assignment inside closure is detected
func o() int {
foo := func() int { return 1 } // ERROR "can inline o.func1" "func literal does not escape"
func(x int) { // ERROR "can inline o.func2"
if x > 10 {
foo = func() int { return 2 } // ERROR "can inline o.func2"
}
}(11) // ERROR "func literal does not escape" "inlining call to o.func2"
return foo()
}
func p() int { // ERROR "can inline p"
return func() int { return 42 }() // ERROR "can inline p.func1" "inlining call to p.func1"
}
func q(x int) int { // ERROR "can inline q"
foo := func() int { return x * 2 } // ERROR "can inline q.func1" "func literal does not escape"
cmd/compile: inline closures with captures When inlining a closure with captured variables, walk up the param chain to find the one that is defined inside the scope into which the function is being inlined, and map occurrences of the captures to temporary inlvars, similarly to what is done for function parameters. No noticeable impact on compilation speed and binary size. Minor improvements to go1 benchmarks on darwin/amd64 name old time/op new time/op delta BinaryTree17-4 2.59s ± 3% 2.58s ± 1% ~ (p=0.470 n=19+19) Fannkuch11-4 3.15s ± 2% 3.15s ± 1% ~ (p=0.647 n=20+19) FmtFprintfEmpty-4 43.7ns ± 3% 43.4ns ± 4% ~ (p=0.178 n=18+20) FmtFprintfString-4 74.0ns ± 2% 77.1ns ± 7% +4.13% (p=0.000 n=20+20) FmtFprintfInt-4 77.2ns ± 3% 79.2ns ± 6% +2.53% (p=0.000 n=20+20) FmtFprintfIntInt-4 112ns ± 4% 112ns ± 2% ~ (p=0.672 n=20+19) FmtFprintfPrefixedInt-4 136ns ± 1% 135ns ± 2% ~ (p=0.827 n=16+20) FmtFprintfFloat-4 232ns ± 2% 233ns ± 1% ~ (p=0.194 n=20+20) FmtManyArgs-4 490ns ± 2% 484ns ± 2% -1.28% (p=0.001 n=20+20) GobDecode-4 6.68ms ± 2% 6.72ms ± 2% ~ (p=0.113 n=20+19) GobEncode-4 5.62ms ± 2% 5.71ms ± 2% +1.64% (p=0.000 n=20+19) Gzip-4 235ms ± 3% 236ms ± 2% ~ (p=0.607 n=20+19) Gunzip-4 37.1ms ± 2% 36.8ms ± 3% ~ (p=0.060 n=20+20) HTTPClientServer-4 61.9µs ± 2% 62.7µs ± 4% +1.24% (p=0.007 n=18+19) JSONEncode-4 12.5ms ± 2% 12.4ms ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 51.6ms ± 3% 51.0ms ± 3% -1.19% (p=0.008 n=20+19) Mandelbrot200-4 4.12ms ± 6% 4.06ms ± 5% ~ (p=0.063 n=20+20) GoParse-4 3.12ms ± 5% 3.10ms ± 2% ~ (p=0.402 n=19+19) RegexpMatchEasy0_32-4 80.7ns ± 2% 75.1ns ± 9% -6.94% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 197ns ± 2% 186ns ± 2% -5.43% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 77.5ns ± 4% 71.9ns ± 7% -7.25% (p=0.000 n=20+18) RegexpMatchEasy1_1K-4 341ns ± 3% 341ns ± 3% ~ (p=0.732 n=20+20) RegexpMatchMedium_32-4 113ns ± 2% 112ns ± 3% ~ (p=0.102 n=20+20) RegexpMatchMedium_1K-4 36.6µs ± 2% 35.8µs ± 2% -2.26% (p=0.000 n=18+20) RegexpMatchHard_32-4 1.75µs ± 3% 1.74µs ± 2% ~ (p=0.473 n=20+19) RegexpMatchHard_1K-4 52.6µs ± 2% 52.0µs ± 3% -1.15% (p=0.005 n=20+20) Revcomp-4 381ms ± 4% 377ms ± 2% ~ (p=0.067 n=20+18) Template-4 57.3ms ± 2% 57.7ms ± 2% ~ (p=0.108 n=20+20) TimeParse-4 291ns ± 3% 292ns ± 2% ~ (p=0.585 n=20+20) TimeFormat-4 314ns ± 3% 315ns ± 1% ~ (p=0.681 n=20+20) [Geo mean] 47.4µs 47.1µs -0.73% name old speed new speed delta GobDecode-4 115MB/s ± 2% 114MB/s ± 2% ~ (p=0.115 n=20+19) GobEncode-4 137MB/s ± 2% 134MB/s ± 2% -1.63% (p=0.000 n=20+19) Gzip-4 82.5MB/s ± 3% 82.4MB/s ± 2% ~ (p=0.612 n=20+19) Gunzip-4 523MB/s ± 2% 528MB/s ± 3% ~ (p=0.060 n=20+20) JSONEncode-4 155MB/s ± 2% 156MB/s ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 37.6MB/s ± 3% 38.1MB/s ± 3% +1.21% (p=0.007 n=20+19) GoParse-4 18.6MB/s ± 4% 18.7MB/s ± 2% ~ (p=0.405 n=19+19) RegexpMatchEasy0_32-4 396MB/s ± 2% 426MB/s ± 8% +7.56% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 5.18GB/s ± 2% 5.48GB/s ± 2% +5.79% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 413MB/s ± 4% 444MB/s ± 6% +7.46% (p=0.000 n=20+19) RegexpMatchEasy1_1K-4 3.00GB/s ± 3% 3.00GB/s ± 3% ~ (p=0.678 n=20+20) RegexpMatchMedium_32-4 8.82MB/s ± 2% 8.90MB/s ± 3% +0.99% (p=0.044 n=20+20) RegexpMatchMedium_1K-4 28.0MB/s ± 2% 28.6MB/s ± 2% +2.32% (p=0.000 n=18+20) RegexpMatchHard_32-4 18.3MB/s ± 3% 18.4MB/s ± 2% ~ (p=0.482 n=20+19) RegexpMatchHard_1K-4 19.5MB/s ± 2% 19.7MB/s ± 3% +1.18% (p=0.004 n=20+20) Revcomp-4 668MB/s ± 4% 674MB/s ± 2% ~ (p=0.066 n=20+18) Template-4 33.8MB/s ± 2% 33.6MB/s ± 2% ~ (p=0.104 n=20+20) [Geo mean] 124MB/s 126MB/s +1.54% Updates #15561 Updates #18270 Change-Id: I980086efe28b36aa27f81577065e2a729ff03d4e Reviewed-on: https://go-review.googlesource.com/72490 Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-21 16:58:37 -06:00
return foo() // ERROR "inlining call to q.func1"
}
func r(z int) int {
foo := func(x int) int { // ERROR "can inline r.func1" "func literal does not escape"
return x + z
}
bar := func(x int) int { // ERROR "func literal does not escape" "can inline r.func2"
return x + func(y int) int { // ERROR "can inline r.func2.1" "can inline r.r.func2.func3"
return 2*y + x*z
}(x) // ERROR "inlining call to r.func2.1"
}
return foo(42) + bar(42) // ERROR "inlining call to r.func1" "inlining call to r.func2" "inlining call to r.r.func2.func3"
}
func s0(x int) int { // ERROR "can inline s0"
foo := func() { // ERROR "can inline s0.func1" "func literal does not escape"
cmd/compile: inline closures with captures When inlining a closure with captured variables, walk up the param chain to find the one that is defined inside the scope into which the function is being inlined, and map occurrences of the captures to temporary inlvars, similarly to what is done for function parameters. No noticeable impact on compilation speed and binary size. Minor improvements to go1 benchmarks on darwin/amd64 name old time/op new time/op delta BinaryTree17-4 2.59s ± 3% 2.58s ± 1% ~ (p=0.470 n=19+19) Fannkuch11-4 3.15s ± 2% 3.15s ± 1% ~ (p=0.647 n=20+19) FmtFprintfEmpty-4 43.7ns ± 3% 43.4ns ± 4% ~ (p=0.178 n=18+20) FmtFprintfString-4 74.0ns ± 2% 77.1ns ± 7% +4.13% (p=0.000 n=20+20) FmtFprintfInt-4 77.2ns ± 3% 79.2ns ± 6% +2.53% (p=0.000 n=20+20) FmtFprintfIntInt-4 112ns ± 4% 112ns ± 2% ~ (p=0.672 n=20+19) FmtFprintfPrefixedInt-4 136ns ± 1% 135ns ± 2% ~ (p=0.827 n=16+20) FmtFprintfFloat-4 232ns ± 2% 233ns ± 1% ~ (p=0.194 n=20+20) FmtManyArgs-4 490ns ± 2% 484ns ± 2% -1.28% (p=0.001 n=20+20) GobDecode-4 6.68ms ± 2% 6.72ms ± 2% ~ (p=0.113 n=20+19) GobEncode-4 5.62ms ± 2% 5.71ms ± 2% +1.64% (p=0.000 n=20+19) Gzip-4 235ms ± 3% 236ms ± 2% ~ (p=0.607 n=20+19) Gunzip-4 37.1ms ± 2% 36.8ms ± 3% ~ (p=0.060 n=20+20) HTTPClientServer-4 61.9µs ± 2% 62.7µs ± 4% +1.24% (p=0.007 n=18+19) JSONEncode-4 12.5ms ± 2% 12.4ms ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 51.6ms ± 3% 51.0ms ± 3% -1.19% (p=0.008 n=20+19) Mandelbrot200-4 4.12ms ± 6% 4.06ms ± 5% ~ (p=0.063 n=20+20) GoParse-4 3.12ms ± 5% 3.10ms ± 2% ~ (p=0.402 n=19+19) RegexpMatchEasy0_32-4 80.7ns ± 2% 75.1ns ± 9% -6.94% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 197ns ± 2% 186ns ± 2% -5.43% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 77.5ns ± 4% 71.9ns ± 7% -7.25% (p=0.000 n=20+18) RegexpMatchEasy1_1K-4 341ns ± 3% 341ns ± 3% ~ (p=0.732 n=20+20) RegexpMatchMedium_32-4 113ns ± 2% 112ns ± 3% ~ (p=0.102 n=20+20) RegexpMatchMedium_1K-4 36.6µs ± 2% 35.8µs ± 2% -2.26% (p=0.000 n=18+20) RegexpMatchHard_32-4 1.75µs ± 3% 1.74µs ± 2% ~ (p=0.473 n=20+19) RegexpMatchHard_1K-4 52.6µs ± 2% 52.0µs ± 3% -1.15% (p=0.005 n=20+20) Revcomp-4 381ms ± 4% 377ms ± 2% ~ (p=0.067 n=20+18) Template-4 57.3ms ± 2% 57.7ms ± 2% ~ (p=0.108 n=20+20) TimeParse-4 291ns ± 3% 292ns ± 2% ~ (p=0.585 n=20+20) TimeFormat-4 314ns ± 3% 315ns ± 1% ~ (p=0.681 n=20+20) [Geo mean] 47.4µs 47.1µs -0.73% name old speed new speed delta GobDecode-4 115MB/s ± 2% 114MB/s ± 2% ~ (p=0.115 n=20+19) GobEncode-4 137MB/s ± 2% 134MB/s ± 2% -1.63% (p=0.000 n=20+19) Gzip-4 82.5MB/s ± 3% 82.4MB/s ± 2% ~ (p=0.612 n=20+19) Gunzip-4 523MB/s ± 2% 528MB/s ± 3% ~ (p=0.060 n=20+20) JSONEncode-4 155MB/s ± 2% 156MB/s ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 37.6MB/s ± 3% 38.1MB/s ± 3% +1.21% (p=0.007 n=20+19) GoParse-4 18.6MB/s ± 4% 18.7MB/s ± 2% ~ (p=0.405 n=19+19) RegexpMatchEasy0_32-4 396MB/s ± 2% 426MB/s ± 8% +7.56% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 5.18GB/s ± 2% 5.48GB/s ± 2% +5.79% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 413MB/s ± 4% 444MB/s ± 6% +7.46% (p=0.000 n=20+19) RegexpMatchEasy1_1K-4 3.00GB/s ± 3% 3.00GB/s ± 3% ~ (p=0.678 n=20+20) RegexpMatchMedium_32-4 8.82MB/s ± 2% 8.90MB/s ± 3% +0.99% (p=0.044 n=20+20) RegexpMatchMedium_1K-4 28.0MB/s ± 2% 28.6MB/s ± 2% +2.32% (p=0.000 n=18+20) RegexpMatchHard_32-4 18.3MB/s ± 3% 18.4MB/s ± 2% ~ (p=0.482 n=20+19) RegexpMatchHard_1K-4 19.5MB/s ± 2% 19.7MB/s ± 3% +1.18% (p=0.004 n=20+20) Revcomp-4 668MB/s ± 4% 674MB/s ± 2% ~ (p=0.066 n=20+18) Template-4 33.8MB/s ± 2% 33.6MB/s ± 2% ~ (p=0.104 n=20+20) [Geo mean] 124MB/s 126MB/s +1.54% Updates #15561 Updates #18270 Change-Id: I980086efe28b36aa27f81577065e2a729ff03d4e Reviewed-on: https://go-review.googlesource.com/72490 Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-21 16:58:37 -06:00
x = x + 1
}
foo() // ERROR "inlining call to s0.func1"
cmd/compile: inline closures with captures When inlining a closure with captured variables, walk up the param chain to find the one that is defined inside the scope into which the function is being inlined, and map occurrences of the captures to temporary inlvars, similarly to what is done for function parameters. No noticeable impact on compilation speed and binary size. Minor improvements to go1 benchmarks on darwin/amd64 name old time/op new time/op delta BinaryTree17-4 2.59s ± 3% 2.58s ± 1% ~ (p=0.470 n=19+19) Fannkuch11-4 3.15s ± 2% 3.15s ± 1% ~ (p=0.647 n=20+19) FmtFprintfEmpty-4 43.7ns ± 3% 43.4ns ± 4% ~ (p=0.178 n=18+20) FmtFprintfString-4 74.0ns ± 2% 77.1ns ± 7% +4.13% (p=0.000 n=20+20) FmtFprintfInt-4 77.2ns ± 3% 79.2ns ± 6% +2.53% (p=0.000 n=20+20) FmtFprintfIntInt-4 112ns ± 4% 112ns ± 2% ~ (p=0.672 n=20+19) FmtFprintfPrefixedInt-4 136ns ± 1% 135ns ± 2% ~ (p=0.827 n=16+20) FmtFprintfFloat-4 232ns ± 2% 233ns ± 1% ~ (p=0.194 n=20+20) FmtManyArgs-4 490ns ± 2% 484ns ± 2% -1.28% (p=0.001 n=20+20) GobDecode-4 6.68ms ± 2% 6.72ms ± 2% ~ (p=0.113 n=20+19) GobEncode-4 5.62ms ± 2% 5.71ms ± 2% +1.64% (p=0.000 n=20+19) Gzip-4 235ms ± 3% 236ms ± 2% ~ (p=0.607 n=20+19) Gunzip-4 37.1ms ± 2% 36.8ms ± 3% ~ (p=0.060 n=20+20) HTTPClientServer-4 61.9µs ± 2% 62.7µs ± 4% +1.24% (p=0.007 n=18+19) JSONEncode-4 12.5ms ± 2% 12.4ms ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 51.6ms ± 3% 51.0ms ± 3% -1.19% (p=0.008 n=20+19) Mandelbrot200-4 4.12ms ± 6% 4.06ms ± 5% ~ (p=0.063 n=20+20) GoParse-4 3.12ms ± 5% 3.10ms ± 2% ~ (p=0.402 n=19+19) RegexpMatchEasy0_32-4 80.7ns ± 2% 75.1ns ± 9% -6.94% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 197ns ± 2% 186ns ± 2% -5.43% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 77.5ns ± 4% 71.9ns ± 7% -7.25% (p=0.000 n=20+18) RegexpMatchEasy1_1K-4 341ns ± 3% 341ns ± 3% ~ (p=0.732 n=20+20) RegexpMatchMedium_32-4 113ns ± 2% 112ns ± 3% ~ (p=0.102 n=20+20) RegexpMatchMedium_1K-4 36.6µs ± 2% 35.8µs ± 2% -2.26% (p=0.000 n=18+20) RegexpMatchHard_32-4 1.75µs ± 3% 1.74µs ± 2% ~ (p=0.473 n=20+19) RegexpMatchHard_1K-4 52.6µs ± 2% 52.0µs ± 3% -1.15% (p=0.005 n=20+20) Revcomp-4 381ms ± 4% 377ms ± 2% ~ (p=0.067 n=20+18) Template-4 57.3ms ± 2% 57.7ms ± 2% ~ (p=0.108 n=20+20) TimeParse-4 291ns ± 3% 292ns ± 2% ~ (p=0.585 n=20+20) TimeFormat-4 314ns ± 3% 315ns ± 1% ~ (p=0.681 n=20+20) [Geo mean] 47.4µs 47.1µs -0.73% name old speed new speed delta GobDecode-4 115MB/s ± 2% 114MB/s ± 2% ~ (p=0.115 n=20+19) GobEncode-4 137MB/s ± 2% 134MB/s ± 2% -1.63% (p=0.000 n=20+19) Gzip-4 82.5MB/s ± 3% 82.4MB/s ± 2% ~ (p=0.612 n=20+19) Gunzip-4 523MB/s ± 2% 528MB/s ± 3% ~ (p=0.060 n=20+20) JSONEncode-4 155MB/s ± 2% 156MB/s ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 37.6MB/s ± 3% 38.1MB/s ± 3% +1.21% (p=0.007 n=20+19) GoParse-4 18.6MB/s ± 4% 18.7MB/s ± 2% ~ (p=0.405 n=19+19) RegexpMatchEasy0_32-4 396MB/s ± 2% 426MB/s ± 8% +7.56% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 5.18GB/s ± 2% 5.48GB/s ± 2% +5.79% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 413MB/s ± 4% 444MB/s ± 6% +7.46% (p=0.000 n=20+19) RegexpMatchEasy1_1K-4 3.00GB/s ± 3% 3.00GB/s ± 3% ~ (p=0.678 n=20+20) RegexpMatchMedium_32-4 8.82MB/s ± 2% 8.90MB/s ± 3% +0.99% (p=0.044 n=20+20) RegexpMatchMedium_1K-4 28.0MB/s ± 2% 28.6MB/s ± 2% +2.32% (p=0.000 n=18+20) RegexpMatchHard_32-4 18.3MB/s ± 3% 18.4MB/s ± 2% ~ (p=0.482 n=20+19) RegexpMatchHard_1K-4 19.5MB/s ± 2% 19.7MB/s ± 3% +1.18% (p=0.004 n=20+20) Revcomp-4 668MB/s ± 4% 674MB/s ± 2% ~ (p=0.066 n=20+18) Template-4 33.8MB/s ± 2% 33.6MB/s ± 2% ~ (p=0.104 n=20+20) [Geo mean] 124MB/s 126MB/s +1.54% Updates #15561 Updates #18270 Change-Id: I980086efe28b36aa27f81577065e2a729ff03d4e Reviewed-on: https://go-review.googlesource.com/72490 Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-21 16:58:37 -06:00
return x
}
func s1(x int) int { // ERROR "can inline s1"
foo := func() int { // ERROR "can inline s1.func1" "func literal does not escape"
cmd/compile: inline closures with captures When inlining a closure with captured variables, walk up the param chain to find the one that is defined inside the scope into which the function is being inlined, and map occurrences of the captures to temporary inlvars, similarly to what is done for function parameters. No noticeable impact on compilation speed and binary size. Minor improvements to go1 benchmarks on darwin/amd64 name old time/op new time/op delta BinaryTree17-4 2.59s ± 3% 2.58s ± 1% ~ (p=0.470 n=19+19) Fannkuch11-4 3.15s ± 2% 3.15s ± 1% ~ (p=0.647 n=20+19) FmtFprintfEmpty-4 43.7ns ± 3% 43.4ns ± 4% ~ (p=0.178 n=18+20) FmtFprintfString-4 74.0ns ± 2% 77.1ns ± 7% +4.13% (p=0.000 n=20+20) FmtFprintfInt-4 77.2ns ± 3% 79.2ns ± 6% +2.53% (p=0.000 n=20+20) FmtFprintfIntInt-4 112ns ± 4% 112ns ± 2% ~ (p=0.672 n=20+19) FmtFprintfPrefixedInt-4 136ns ± 1% 135ns ± 2% ~ (p=0.827 n=16+20) FmtFprintfFloat-4 232ns ± 2% 233ns ± 1% ~ (p=0.194 n=20+20) FmtManyArgs-4 490ns ± 2% 484ns ± 2% -1.28% (p=0.001 n=20+20) GobDecode-4 6.68ms ± 2% 6.72ms ± 2% ~ (p=0.113 n=20+19) GobEncode-4 5.62ms ± 2% 5.71ms ± 2% +1.64% (p=0.000 n=20+19) Gzip-4 235ms ± 3% 236ms ± 2% ~ (p=0.607 n=20+19) Gunzip-4 37.1ms ± 2% 36.8ms ± 3% ~ (p=0.060 n=20+20) HTTPClientServer-4 61.9µs ± 2% 62.7µs ± 4% +1.24% (p=0.007 n=18+19) JSONEncode-4 12.5ms ± 2% 12.4ms ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 51.6ms ± 3% 51.0ms ± 3% -1.19% (p=0.008 n=20+19) Mandelbrot200-4 4.12ms ± 6% 4.06ms ± 5% ~ (p=0.063 n=20+20) GoParse-4 3.12ms ± 5% 3.10ms ± 2% ~ (p=0.402 n=19+19) RegexpMatchEasy0_32-4 80.7ns ± 2% 75.1ns ± 9% -6.94% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 197ns ± 2% 186ns ± 2% -5.43% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 77.5ns ± 4% 71.9ns ± 7% -7.25% (p=0.000 n=20+18) RegexpMatchEasy1_1K-4 341ns ± 3% 341ns ± 3% ~ (p=0.732 n=20+20) RegexpMatchMedium_32-4 113ns ± 2% 112ns ± 3% ~ (p=0.102 n=20+20) RegexpMatchMedium_1K-4 36.6µs ± 2% 35.8µs ± 2% -2.26% (p=0.000 n=18+20) RegexpMatchHard_32-4 1.75µs ± 3% 1.74µs ± 2% ~ (p=0.473 n=20+19) RegexpMatchHard_1K-4 52.6µs ± 2% 52.0µs ± 3% -1.15% (p=0.005 n=20+20) Revcomp-4 381ms ± 4% 377ms ± 2% ~ (p=0.067 n=20+18) Template-4 57.3ms ± 2% 57.7ms ± 2% ~ (p=0.108 n=20+20) TimeParse-4 291ns ± 3% 292ns ± 2% ~ (p=0.585 n=20+20) TimeFormat-4 314ns ± 3% 315ns ± 1% ~ (p=0.681 n=20+20) [Geo mean] 47.4µs 47.1µs -0.73% name old speed new speed delta GobDecode-4 115MB/s ± 2% 114MB/s ± 2% ~ (p=0.115 n=20+19) GobEncode-4 137MB/s ± 2% 134MB/s ± 2% -1.63% (p=0.000 n=20+19) Gzip-4 82.5MB/s ± 3% 82.4MB/s ± 2% ~ (p=0.612 n=20+19) Gunzip-4 523MB/s ± 2% 528MB/s ± 3% ~ (p=0.060 n=20+20) JSONEncode-4 155MB/s ± 2% 156MB/s ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 37.6MB/s ± 3% 38.1MB/s ± 3% +1.21% (p=0.007 n=20+19) GoParse-4 18.6MB/s ± 4% 18.7MB/s ± 2% ~ (p=0.405 n=19+19) RegexpMatchEasy0_32-4 396MB/s ± 2% 426MB/s ± 8% +7.56% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 5.18GB/s ± 2% 5.48GB/s ± 2% +5.79% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 413MB/s ± 4% 444MB/s ± 6% +7.46% (p=0.000 n=20+19) RegexpMatchEasy1_1K-4 3.00GB/s ± 3% 3.00GB/s ± 3% ~ (p=0.678 n=20+20) RegexpMatchMedium_32-4 8.82MB/s ± 2% 8.90MB/s ± 3% +0.99% (p=0.044 n=20+20) RegexpMatchMedium_1K-4 28.0MB/s ± 2% 28.6MB/s ± 2% +2.32% (p=0.000 n=18+20) RegexpMatchHard_32-4 18.3MB/s ± 3% 18.4MB/s ± 2% ~ (p=0.482 n=20+19) RegexpMatchHard_1K-4 19.5MB/s ± 2% 19.7MB/s ± 3% +1.18% (p=0.004 n=20+20) Revcomp-4 668MB/s ± 4% 674MB/s ± 2% ~ (p=0.066 n=20+18) Template-4 33.8MB/s ± 2% 33.6MB/s ± 2% ~ (p=0.104 n=20+20) [Geo mean] 124MB/s 126MB/s +1.54% Updates #15561 Updates #18270 Change-Id: I980086efe28b36aa27f81577065e2a729ff03d4e Reviewed-on: https://go-review.googlesource.com/72490 Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-21 16:58:37 -06:00
return x
}
x = x + 1
return foo() // ERROR "inlining call to s1.func1"
cmd/compile: inline closures with captures When inlining a closure with captured variables, walk up the param chain to find the one that is defined inside the scope into which the function is being inlined, and map occurrences of the captures to temporary inlvars, similarly to what is done for function parameters. No noticeable impact on compilation speed and binary size. Minor improvements to go1 benchmarks on darwin/amd64 name old time/op new time/op delta BinaryTree17-4 2.59s ± 3% 2.58s ± 1% ~ (p=0.470 n=19+19) Fannkuch11-4 3.15s ± 2% 3.15s ± 1% ~ (p=0.647 n=20+19) FmtFprintfEmpty-4 43.7ns ± 3% 43.4ns ± 4% ~ (p=0.178 n=18+20) FmtFprintfString-4 74.0ns ± 2% 77.1ns ± 7% +4.13% (p=0.000 n=20+20) FmtFprintfInt-4 77.2ns ± 3% 79.2ns ± 6% +2.53% (p=0.000 n=20+20) FmtFprintfIntInt-4 112ns ± 4% 112ns ± 2% ~ (p=0.672 n=20+19) FmtFprintfPrefixedInt-4 136ns ± 1% 135ns ± 2% ~ (p=0.827 n=16+20) FmtFprintfFloat-4 232ns ± 2% 233ns ± 1% ~ (p=0.194 n=20+20) FmtManyArgs-4 490ns ± 2% 484ns ± 2% -1.28% (p=0.001 n=20+20) GobDecode-4 6.68ms ± 2% 6.72ms ± 2% ~ (p=0.113 n=20+19) GobEncode-4 5.62ms ± 2% 5.71ms ± 2% +1.64% (p=0.000 n=20+19) Gzip-4 235ms ± 3% 236ms ± 2% ~ (p=0.607 n=20+19) Gunzip-4 37.1ms ± 2% 36.8ms ± 3% ~ (p=0.060 n=20+20) HTTPClientServer-4 61.9µs ± 2% 62.7µs ± 4% +1.24% (p=0.007 n=18+19) JSONEncode-4 12.5ms ± 2% 12.4ms ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 51.6ms ± 3% 51.0ms ± 3% -1.19% (p=0.008 n=20+19) Mandelbrot200-4 4.12ms ± 6% 4.06ms ± 5% ~ (p=0.063 n=20+20) GoParse-4 3.12ms ± 5% 3.10ms ± 2% ~ (p=0.402 n=19+19) RegexpMatchEasy0_32-4 80.7ns ± 2% 75.1ns ± 9% -6.94% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 197ns ± 2% 186ns ± 2% -5.43% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 77.5ns ± 4% 71.9ns ± 7% -7.25% (p=0.000 n=20+18) RegexpMatchEasy1_1K-4 341ns ± 3% 341ns ± 3% ~ (p=0.732 n=20+20) RegexpMatchMedium_32-4 113ns ± 2% 112ns ± 3% ~ (p=0.102 n=20+20) RegexpMatchMedium_1K-4 36.6µs ± 2% 35.8µs ± 2% -2.26% (p=0.000 n=18+20) RegexpMatchHard_32-4 1.75µs ± 3% 1.74µs ± 2% ~ (p=0.473 n=20+19) RegexpMatchHard_1K-4 52.6µs ± 2% 52.0µs ± 3% -1.15% (p=0.005 n=20+20) Revcomp-4 381ms ± 4% 377ms ± 2% ~ (p=0.067 n=20+18) Template-4 57.3ms ± 2% 57.7ms ± 2% ~ (p=0.108 n=20+20) TimeParse-4 291ns ± 3% 292ns ± 2% ~ (p=0.585 n=20+20) TimeFormat-4 314ns ± 3% 315ns ± 1% ~ (p=0.681 n=20+20) [Geo mean] 47.4µs 47.1µs -0.73% name old speed new speed delta GobDecode-4 115MB/s ± 2% 114MB/s ± 2% ~ (p=0.115 n=20+19) GobEncode-4 137MB/s ± 2% 134MB/s ± 2% -1.63% (p=0.000 n=20+19) Gzip-4 82.5MB/s ± 3% 82.4MB/s ± 2% ~ (p=0.612 n=20+19) Gunzip-4 523MB/s ± 2% 528MB/s ± 3% ~ (p=0.060 n=20+20) JSONEncode-4 155MB/s ± 2% 156MB/s ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 37.6MB/s ± 3% 38.1MB/s ± 3% +1.21% (p=0.007 n=20+19) GoParse-4 18.6MB/s ± 4% 18.7MB/s ± 2% ~ (p=0.405 n=19+19) RegexpMatchEasy0_32-4 396MB/s ± 2% 426MB/s ± 8% +7.56% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 5.18GB/s ± 2% 5.48GB/s ± 2% +5.79% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 413MB/s ± 4% 444MB/s ± 6% +7.46% (p=0.000 n=20+19) RegexpMatchEasy1_1K-4 3.00GB/s ± 3% 3.00GB/s ± 3% ~ (p=0.678 n=20+20) RegexpMatchMedium_32-4 8.82MB/s ± 2% 8.90MB/s ± 3% +0.99% (p=0.044 n=20+20) RegexpMatchMedium_1K-4 28.0MB/s ± 2% 28.6MB/s ± 2% +2.32% (p=0.000 n=18+20) RegexpMatchHard_32-4 18.3MB/s ± 3% 18.4MB/s ± 2% ~ (p=0.482 n=20+19) RegexpMatchHard_1K-4 19.5MB/s ± 2% 19.7MB/s ± 3% +1.18% (p=0.004 n=20+20) Revcomp-4 668MB/s ± 4% 674MB/s ± 2% ~ (p=0.066 n=20+18) Template-4 33.8MB/s ± 2% 33.6MB/s ± 2% ~ (p=0.104 n=20+20) [Geo mean] 124MB/s 126MB/s +1.54% Updates #15561 Updates #18270 Change-Id: I980086efe28b36aa27f81577065e2a729ff03d4e Reviewed-on: https://go-review.googlesource.com/72490 Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-10-21 16:58:37 -06:00
}
func switchBreak(x, y int) int { // ERROR "can inline switchBreak"
var n int
switch x {
case 0:
n = 1
Done:
switch y {
case 0:
n += 10
break Done
}
n = 2
}
return n
}
func switchType(x interface{}) int { // ERROR "can inline switchType" "x does not escape"
switch x.(type) {
case int:
return x.(int)
default:
return 0
}
}
// Test that switches on constant things, with constant cases, only cost anything for
// the case that matches. See issue 50253.
func switchConst1(p func(string)) { // ERROR "can inline switchConst" "p does not escape"
const c = 1
switch c {
case 0:
p("zero")
case 1:
p("one")
case 2:
p("two")
default:
p("other")
}
}
func switchConst2() string { // ERROR "can inline switchConst2"
switch runtime.GOOS {
case "linux":
return "Leenooks"
case "windows":
return "Windoze"
case "darwin":
return "MackBone"
case "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", "24", "25", "26", "27", "28", "29", "30", "31", "32", "33", "34", "35", "36", "37", "38", "39", "40", "41", "42", "43", "44", "45", "46", "47", "48", "49", "50", "51", "52", "53", "54", "55", "56", "57", "58", "59", "60", "61", "62", "63", "64", "65", "66", "67", "68", "69", "70", "71", "72", "73", "74", "75", "76", "77", "78", "79", "80", "81", "82", "83", "84", "85", "86", "87", "88", "89", "90", "91", "92", "93", "94", "95", "96", "97", "98", "99", "100":
return "Numbers"
default:
return "oh nose!"
}
}
func switchConst3() string { // ERROR "can inline switchConst3"
switch runtime.GOOS {
case "Linux":
panic("Linux")
case "Windows":
panic("Windows")
case "Darwin":
panic("Darwin")
case "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16", "17", "18", "19", "20", "21", "22", "23", "24", "25", "26", "27", "28", "29", "30", "31", "32", "33", "34", "35", "36", "37", "38", "39", "40", "41", "42", "43", "44", "45", "46", "47", "48", "49", "50", "51", "52", "53", "54", "55", "56", "57", "58", "59", "60", "61", "62", "63", "64", "65", "66", "67", "68", "69", "70", "71", "72", "73", "74", "75", "76", "77", "78", "79", "80", "81", "82", "83", "84", "85", "86", "87", "88", "89", "90", "91", "92", "93", "94", "95", "96", "97", "98", "99", "100":
panic("Numbers")
default:
return "oh nose!"
}
}
cmd/compile: better code generation for constant-fold switch CL 399694 added constant-fold switch early in compilation. So function: func f() string { switch intSize { case 32: return "32" case 64: return "64" default: panic("unreachable") } } will be constant-fold to: func f() string { switch intSize { case 64: return "64" } } When this function get inlined, there is a check whether we can delay declaring the result parameter until the "return" statement. For the original function, we can't delay the result, because there's more than one return statement. However, the constant-fold one can, because there's on one return statement in the body now. The result parameter ~R0 ends up declaring inside the switch statement scope. Now, when walking the switch statement, it's re-written into if-else statement. Without typecheck.EvalConst, the if condition "if 64 == 64" is passed as-is to the ssa generation pass. Because "64 == 64" is not a constant, the ssagen creates normal blocks for branching the results. This confuses the liveness analysis, because ~R0 is only live inside the if block. With typecheck.EvalConst, "64 == 64" is evaluated to "true", so ssagen can branch the result without emitting conditional blocks. Instead, the constant-fold can be re-written as: switch { case true: // Body } So it does not depend on the delay results check during inlining. Adding a test, which will fail when typecheck.EvalConst is removed, so we can do the cleanup without breaking things. Change-Id: I638730bb147140de84260653741431b807ff2f15 Reviewed-on: https://go-review.googlesource.com/c/go/+/484316 Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-04-13 01:51:05 -06:00
func switchConst4() { // ERROR "can inline switchConst4"
const intSize = 32 << (^uint(0) >> 63)
want := func() string { // ERROR "can inline switchConst4.func1"
switch intSize {
case 32:
return "32"
case 64:
return "64"
default:
panic("unreachable")
}
}() // ERROR "inlining call to switchConst4.func1"
_ = want
}
func inlineRangeIntoMe(data []int) { // ERROR "can inline inlineRangeIntoMe" "data does not escape"
rangeFunc(data, 12) // ERROR "inlining call to rangeFunc"
}
func rangeFunc(xs []int, b int) int { // ERROR "can inline rangeFunc" "xs does not escape"
for i, x := range xs {
if x == b {
return i
}
}
return -1
}
type T struct{}
func (T) meth(int, int) {} // ERROR "can inline T.meth"
func k() (T, int, int) { return T{}, 0, 0 } // ERROR "can inline k"
func f3() { // ERROR "can inline f3"
T.meth(k()) // ERROR "inlining call to k" "inlining call to T.meth"
// ERRORAUTO "inlining call to T.meth"
}
func small1() { // ERROR "can inline small1"
runtime.GC()
}
func small2() int { // ERROR "can inline small2"
return runtime.GOMAXPROCS(0)
}
func small3(t T) { // ERROR "can inline small3"
t.meth2(3, 5)
}
func small4(t T) { // not inlineable - has 2 calls.
t.meth2(runtime.GOMAXPROCS(0), 5)
}
func (T) meth2(int, int) { // not inlineable - has 2 calls.
runtime.GC()
runtime.GC()
}
cmd/compile: allow mid-stack inlining when there is a cycle of recursion We still disallow inlining for an immediately-recursive function, but allow inlining if a function is in a recursion chain. If all functions in the recursion chain are simple, then we could inline forever down the recursion chain (eventually running out of stack on the compiler), so we add a map to keep track of the functions we have already inlined at a call site. We stop inlining when we reach a function that we have already inlined in the recursive chain. Of course, normally the inlining will have stopped earlier, because of the cost function. We could also limit the depth of inlining by a simple count (say, limit max inlining of 10 at any given site). Would that limit other opportunities too much? Added a test in test/inline.go. runtime.BenchmarkStackCopyNoCache() is also already a good test that triggers the check to stop inlining when we reach the start of the recursive chain again. For the bent benchmark suite, the performance improvement was mostly not statistically significant, but the geomean averaged out to: -0.68%. The text size increase was less than .1% for all bent benchmarks. The cmd/go text size increase was 0.02% and the cmd/compile text size increase was .1%. Fixes #29737 Change-Id: I892fa84bb07a947b3125ec8f25ed0e508bf2bdf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/226818 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-03-31 21:24:05 -06:00
// Issue #29737 - make sure we can do inlining for a chain of recursive functions
func ee() { // ERROR "can inline ee"
ff(100) // ERROR "inlining call to ff" "inlining call to gg" "inlining call to hh"
}
func ff(x int) { // ERROR "can inline ff"
if x < 0 {
return
}
gg(x - 1) // ERROR "inlining call to gg" "inlining call to hh"
cmd/compile: allow mid-stack inlining when there is a cycle of recursion We still disallow inlining for an immediately-recursive function, but allow inlining if a function is in a recursion chain. If all functions in the recursion chain are simple, then we could inline forever down the recursion chain (eventually running out of stack on the compiler), so we add a map to keep track of the functions we have already inlined at a call site. We stop inlining when we reach a function that we have already inlined in the recursive chain. Of course, normally the inlining will have stopped earlier, because of the cost function. We could also limit the depth of inlining by a simple count (say, limit max inlining of 10 at any given site). Would that limit other opportunities too much? Added a test in test/inline.go. runtime.BenchmarkStackCopyNoCache() is also already a good test that triggers the check to stop inlining when we reach the start of the recursive chain again. For the bent benchmark suite, the performance improvement was mostly not statistically significant, but the geomean averaged out to: -0.68%. The text size increase was less than .1% for all bent benchmarks. The cmd/go text size increase was 0.02% and the cmd/compile text size increase was .1%. Fixes #29737 Change-Id: I892fa84bb07a947b3125ec8f25ed0e508bf2bdf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/226818 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-03-31 21:24:05 -06:00
}
func gg(x int) { // ERROR "can inline gg"
hh(x - 1) // ERROR "inlining call to hh" "inlining call to ff"
cmd/compile: allow mid-stack inlining when there is a cycle of recursion We still disallow inlining for an immediately-recursive function, but allow inlining if a function is in a recursion chain. If all functions in the recursion chain are simple, then we could inline forever down the recursion chain (eventually running out of stack on the compiler), so we add a map to keep track of the functions we have already inlined at a call site. We stop inlining when we reach a function that we have already inlined in the recursive chain. Of course, normally the inlining will have stopped earlier, because of the cost function. We could also limit the depth of inlining by a simple count (say, limit max inlining of 10 at any given site). Would that limit other opportunities too much? Added a test in test/inline.go. runtime.BenchmarkStackCopyNoCache() is also already a good test that triggers the check to stop inlining when we reach the start of the recursive chain again. For the bent benchmark suite, the performance improvement was mostly not statistically significant, but the geomean averaged out to: -0.68%. The text size increase was less than .1% for all bent benchmarks. The cmd/go text size increase was 0.02% and the cmd/compile text size increase was .1%. Fixes #29737 Change-Id: I892fa84bb07a947b3125ec8f25ed0e508bf2bdf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/226818 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-03-31 21:24:05 -06:00
}
func hh(x int) { // ERROR "can inline hh"
ff(x - 1) // ERROR "inlining call to ff" "inlining call to gg"
cmd/compile: allow mid-stack inlining when there is a cycle of recursion We still disallow inlining for an immediately-recursive function, but allow inlining if a function is in a recursion chain. If all functions in the recursion chain are simple, then we could inline forever down the recursion chain (eventually running out of stack on the compiler), so we add a map to keep track of the functions we have already inlined at a call site. We stop inlining when we reach a function that we have already inlined in the recursive chain. Of course, normally the inlining will have stopped earlier, because of the cost function. We could also limit the depth of inlining by a simple count (say, limit max inlining of 10 at any given site). Would that limit other opportunities too much? Added a test in test/inline.go. runtime.BenchmarkStackCopyNoCache() is also already a good test that triggers the check to stop inlining when we reach the start of the recursive chain again. For the bent benchmark suite, the performance improvement was mostly not statistically significant, but the geomean averaged out to: -0.68%. The text size increase was less than .1% for all bent benchmarks. The cmd/go text size increase was 0.02% and the cmd/compile text size increase was .1%. Fixes #29737 Change-Id: I892fa84bb07a947b3125ec8f25ed0e508bf2bdf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/226818 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2020-03-31 21:24:05 -06:00
}
// Issue #14768 - make sure we can inline for loops.
func for1(fn func() bool) { // ERROR "can inline for1" "fn does not escape"
for {
if fn() {
break
} else {
continue
}
}
}
func for2(fn func() bool) { // ERROR "can inline for2" "fn does not escape"
Loop:
for {
if fn() {
break Loop
} else {
continue Loop
}
}
}
// Issue #18493 - make sure we can do inlining of functions with a method value
type T1 struct{}
func (a T1) meth(val int) int { // ERROR "can inline T1.meth"
return val + 5
}
func getMeth(t1 T1) func(int) int { // ERROR "can inline getMeth"
return t1.meth // ERROR "t1.meth escapes to heap"
// ERRORAUTO "inlining call to T1.meth"
}
func ii() { // ERROR "can inline ii"
var t1 T1
f := getMeth(t1) // ERROR "inlining call to getMeth" "t1.meth does not escape"
_ = f(3)
}
// Issue #42194 - make sure that functions evaluated in
// go and defer statements can be inlined.
func gd1(int) {
defer gd1(gd2()) // ERROR "inlining call to gd2"
defer gd3()() // ERROR "inlining call to gd3"
go gd1(gd2()) // ERROR "inlining call to gd2"
go gd3()() // ERROR "inlining call to gd3"
}
func gd2() int { // ERROR "can inline gd2"
return 1
}
func gd3() func() { // ERROR "can inline gd3"
return ii
}
// Issue #42788 - ensure ODEREF OCONVNOP* OADDR is low cost.
func EncodeQuad(d []uint32, x [6]float32) { // ERROR "can inline EncodeQuad" "d does not escape"
_ = d[:6]
d[0] = float32bits(x[0]) // ERROR "inlining call to float32bits"
d[1] = float32bits(x[1]) // ERROR "inlining call to float32bits"
d[2] = float32bits(x[2]) // ERROR "inlining call to float32bits"
d[3] = float32bits(x[3]) // ERROR "inlining call to float32bits"
d[4] = float32bits(x[4]) // ERROR "inlining call to float32bits"
d[5] = float32bits(x[5]) // ERROR "inlining call to float32bits"
}
// float32bits is a copy of math.Float32bits to ensure that
// these tests pass with `-gcflags=-l`.
func float32bits(f float32) uint32 { // ERROR "can inline float32bits"
return *(*uint32)(unsafe.Pointer(&f))
}
// Ensure OCONVNOP is zero cost.
func Conv(v uint64) uint64 { // ERROR "can inline Conv"
return conv2(conv2(conv2(v))) // ERROR "inlining call to (conv1|conv2)"
}
func conv2(v uint64) uint64 { // ERROR "can inline conv2"
return conv1(conv1(conv1(conv1(v)))) // ERROR "inlining call to conv1"
}
func conv1(v uint64) uint64 { // ERROR "can inline conv1"
return uint64(uint64(uint64(uint64(uint64(uint64(uint64(uint64(uint64(uint64(uint64(v)))))))))))
}
func select1(x, y chan bool) int { // ERROR "can inline select1" "x does not escape" "y does not escape"
select {
case <-x:
return 1
case <-y:
return 2
}
}
func select2(x, y chan bool) { // ERROR "can inline select2" "x does not escape" "y does not escape"
loop: // test that labeled select can be inlined.
select {
case <-x:
break loop
case <-y:
}
}
func inlineSelect2(x, y chan bool) { // ERROR "can inline inlineSelect2" ERROR "x does not escape" "y does not escape"
loop:
for i := 0; i < 5; i++ {
if i == 3 {
break loop
}
select2(x, y) // ERROR "inlining call to select2"
}
}