Previous CLs optimized direct use of abi.Type, but reflect.Type is
indirected, so was not benefiting.
For TypeFor, we can use toRType directly without a nil check because the
types are statically known.
Normally, I'd think SSA would remove the nil check, but due to some
oddity (specifically, late fuse being required to remove the nil check,
but opt doesn't run that late) means that the nil check persists and
gets in the way.
Manually writing the code in this instance seems to fix the problem.
It also exposed another problem; depending on the ordering, writeType
could get to a type symbol before SSA, thereby preventing Extra from
being created on the symbol for later lookups that don't go through
TypeLinksym directly. In writeType, for non-shape types, call
TypeLinksym to ensure that the type is set up for later callers. That
change itself passed toolstash -cmp.
All up, this stack put through compilecmp shows a lot of improvement in
various reflect-using packages, and reflect itself. It is too big to fit
in the commit message but here's some info:
compilecmp master -> HEAD
master (d767064170): cmd/compile: mark abi.PtrType.Elem sym as used
HEAD (846a94c568): cmd/compile, reflect: further allow inlining of TypeFor
file before after Δ %
addr2line 3735911 3735391 -520 -0.014%
asm 6382235 6382091 -144 -0.002%
buildid 3608568 3608360 -208 -0.006%
cgo 5951816 5951480 -336 -0.006%
compile 28362080 28339772 -22308 -0.079%
cover 6668686 6661414 -7272 -0.109%
dist 4311961 4311425 -536 -0.012%
fix 3771706 3771474 -232 -0.006%
link 8686073 8684993 -1080 -0.012%
nm 3715923 3715459 -464 -0.012%
objdump 6074366 6073774 -592 -0.010%
pack 3025653 3025277 -376 -0.012%
pprof 18269485 18261653 -7832 -0.043%
test2json 3442726 3438390 -4336 -0.126%
trace 16984831 16981767 -3064 -0.018%
vet 10701931 10696355 -5576 -0.052%
total 133693951 133639075 -54876 -0.041%
runtime
runtime.stkobjinit 240 -> 165 (-31.25%)
runtime [cmd/compile]
runtime.stkobjinit 240 -> 165 (-31.25%)
reflect
reflect.Value.Seq2.func3 309 -> 245 (-20.71%)
reflect.Value.Seq2.func1.1 281 -> 198 (-29.54%)
reflect.Value.Seq.func1.1 242 -> 165 (-31.82%)
reflect.Value.Seq2.func2 360 -> 285 (-20.83%)
reflect.Value.Seq.func4 281 -> 239 (-14.95%)
reflect.Value.Seq2.func4 399 -> 284 (-28.82%)
reflect.Value.Seq.func2 271 -> 230 (-15.13%)
reflect.TypeFor[go.shape.uint64] 33 -> 18 (-45.45%)
reflect.Value.Seq.func3 219 -> 178 (-18.72%)
reflect [cmd/compile]
reflect.Value.Seq2.func2 360 -> 285 (-20.83%)
reflect.Value.Seq.func4 281 -> 239 (-14.95%)
reflect.Value.Seq.func2 271 -> 230 (-15.13%)
reflect.Value.Seq.func1.1 242 -> 165 (-31.82%)
reflect.Value.Seq2.func1.1 281 -> 198 (-29.54%)
reflect.Value.Seq2.func3 309 -> 245 (-20.71%)
reflect.Value.Seq.func3 219 -> 178 (-18.72%)
reflect.TypeFor[go.shape.uint64] 33 -> 18 (-45.45%)
reflect.Value.Seq2.func4 399 -> 284 (-28.82%)
fmt
fmt.(*pp).fmtBytes 1723 -> 1691 (-1.86%)
database/sql/driver
reflect.TypeFor[go.shape.interface 33 -> 18 (-45.45%)
database/sql/driver.init 72 -> 57 (-20.83%)
Change-Id: I9eb750cf0b7ebf532589f939431feb0a899e42ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/701301
Reviewed-by: Mark Freeman <markfreeman@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The test directory contains tests of the Go tool chain and runtime.
It includes black box tests, regression tests, and error output tests.
They are run as part of all.bash.
To run just these tests, execute:
../bin/go test cmd/internal/testdir
To run just tests from specified files in this directory, execute:
../bin/go test cmd/internal/testdir -run='Test/(file1.go|file2.go|...)'
Standard library tests should be written as regular Go tests in the appropriate package.
The tool chain and runtime also have regular Go tests in their packages.
The main reasons to add a new test to this directory are:
it is most naturally expressed using the test runner; or
it is also applicable to gccgo and other Go tool chains.