mirror of
https://github.com/golang/go
synced 2024-11-24 01:30:10 -07:00
77ccb16eb1
Inlining refuses to inline bodies containing an actual function call, so that
if that call or a child uses runtime.Caller it cannot observe
the inlining.
However, inlining was also refusing to inline bodies that contained
function calls that were themselves inlined away. For example:
func f() int {
return f1()
}
func f1() int {
return f2()
}
func f2() int {
return 2
}
The f2 call in f1 would be inlined, but the f1 call in f would not,
because f1's call to f2 blocked the inlining, despite itself eventually
being inlined away.
Account properly for this kind of transitive inlining and enable.
Also bump the inlining budget a bit, so that the runtime's
heapBits.next is inlined.
This reduces the time for '6g *.go' in html/template by around 12% (!).
(For what it's worth, closing Chrome reduces the time by about 17%.)
Change-Id: If1aa673bf3e583082dcfb5f223e67355c984bfc1
Reviewed-on: https://go-review.googlesource.com/5952
Reviewed-by: Austin Clements <austin@google.com>
25 lines
794 B
Go
25 lines
794 B
Go
// errorcheck -0 -m
|
|
|
|
// 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 "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"
|
|
}
|