| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I96ea268ecceea75a24303526ed2f17c8a5e142c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/522438
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
|
|
This patch contains the linker changes needed to enable deadcoding of
large unreferenced map variables, in combination with a previous
compiler change. We add a new cleanup function that runs just after
deadcode that looks for relocations in "init" funcs that are weak, of
type R_CALL (and siblings), and are targeting an unreachable function.
If we find such a relocation, after checking to make sure it targets a
map.init.XXX helper, we redirect the relocation to a point to a no-op
routine ("mapinitnoop") in the runtime.
Compilebench results for this change:
│ out.base.txt │ out.wrap.txt │
│ sec/op │ sec/op vs base │
Template 218.6m ± 2% 221.1m ± 1% ~ (p=0.129 n=39)
Unicode 180.5m ± 1% 178.9m ± 1% -0.93% (p=0.006 n=39)
GoTypes 1.162 ± 1% 1.156 ± 1% ~ (p=0.850 n=39)
Compiler 143.6m ± 1% 142.6m ± 1% ~ (p=0.743 n=39)
SSA 8.698 ± 1% 8.719 ± 1% ~ (p=0.145 n=39)
Flate 142.6m ± 1% 143.9m ± 3% ~ (p=0.287 n=39)
GoParser 247.7m ± 1% 248.8m ± 1% ~ (p=0.265 n=39)
Reflect 588.0m ± 1% 590.4m ± 1% ~ (p=0.269 n=39)
Tar 198.5m ± 1% 201.3m ± 1% +1.38% (p=0.005 n=39)
XML 259.1m ± 1% 260.0m ± 1% ~ (p=0.376 n=39)
LinkCompiler 746.8m ± 2% 747.8m ± 1% ~ (p=0.706 n=39)
ExternalLinkCompiler 1.906 ± 0% 1.902 ± 1% ~ (p=0.207 n=40)
LinkWithoutDebugCompiler 522.4m ± 21% 471.1m ± 1% -9.81% (p=0.000 n=40)
StdCmd 21.32 ± 0% 21.39 ± 0% +0.32% (p=0.035 n=40)
geomean 609.2m 606.0m -0.53%
│ out.base.txt │ out.wrap.txt │
│ user-sec/op │ user-sec/op vs base │
Template 401.9m ± 3% 406.9m ± 2% ~ (p=0.291 n=39)
Unicode 191.9m ± 6% 196.1m ± 3% ~ (p=0.052 n=39)
GoTypes 3.967 ± 3% 4.056 ± 1% ~ (p=0.099 n=39)
Compiler 171.1m ± 3% 173.4m ± 3% ~ (p=0.415 n=39)
SSA 30.04 ± 4% 30.25 ± 4% ~ (p=0.106 n=39)
Flate 246.3m ± 3% 248.9m ± 4% ~ (p=0.499 n=39)
GoParser 518.7m ± 1% 520.6m ± 2% ~ (p=0.531 n=39)
Reflect 1.670 ± 1% 1.656 ± 2% ~ (p=0.137 n=39)
Tar 352.7m ± 2% 360.3m ± 2% ~ (p=0.117 n=39)
XML 528.8m ± 2% 521.1m ± 2% ~ (p=0.296 n=39)
LinkCompiler 1.128 ± 2% 1.140 ± 2% ~ (p=0.324 n=39)
ExternalLinkCompiler 2.165 ± 2% 2.147 ± 2% ~ (p=0.537 n=40)
LinkWithoutDebugCompiler 484.2m ± 4% 490.7m ± 3% ~ (p=0.897 n=40)
geomean 818.5m 825.1m +0.80%
│ out.base.txt │ out.wrap.txt │
│ text-bytes │ text-bytes vs base │
HelloSize 766.0Ki ± 0% 766.0Ki ± 0% ~ (p=1.000 n=40) ¹
CmdGoSize 10.02Mi ± 0% 10.02Mi ± 0% -0.03% (n=40)
geomean 2.738Mi 2.738Mi -0.01%
¹ all samples are equal
│ out.base.txt │ out.wrap.txt │
│ data-bytes │ data-bytes vs base │
HelloSize 14.17Ki ± 0% 14.17Ki ± 0% ~ (p=1.000 n=40) ¹
CmdGoSize 308.3Ki ± 0% 298.5Ki ± 0% -3.19% (n=40)
geomean 66.10Ki 65.04Ki -1.61%
¹ all samples are equal
│ out.base.txt │ out.wrap.txt │
│ bss-bytes │ bss-bytes vs base │
HelloSize 197.3Ki ± 0% 197.3Ki ± 0% ~ (p=1.000 n=40) ¹
CmdGoSize 228.2Ki ± 0% 228.1Ki ± 0% -0.01% (n=40)
geomean 212.2Ki 212.1Ki -0.01%
¹ all samples are equal
│ out.base.txt │ out.wrap.txt │
│ exe-bytes │ exe-bytes vs base │
HelloSize 1.192Mi ± 0% 1.192Mi ± 0% +0.00% (p=0.000 n=40)
CmdGoSize 14.85Mi ± 0% 14.83Mi ± 0% -0.09% (n=40)
geomean 4.207Mi 4.205Mi -0.05%
Also tested for any linker changes by benchmarking relink of k8s
"kubelet"; no changes to speak of there.
Updates #2559.
Updates #36021.
Updates #14840.
Change-Id: I4cc5370b3f20679a1065aaaf87bdf2881e257631
Reviewed-on: https://go-review.googlesource.com/c/go/+/463395
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
testenv.Command sets a default timeout based on the test's deadline
and sends SIGQUIT (where supported) in case of a hang.
Change-Id: I25a67aa5793c6fa977ff6d4dc59ca1533bf58d41
Reviewed-on: https://go-review.googlesource.com/c/go/+/450702
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
|
|
As it can't appear in user package paths.
There is a hack for handling "go:buildid" and "type:*" on windows/386.
Previously, windows/386 requires underscore prefix on external symbols,
but that's only applied for SHOSTOBJ/SUNDEFEXT or cgo export symbols.
"go.buildid" is STEXT, "type.*" is STYPE, thus they are not prefixed
with underscore.
In external linking mode, the external linker can't resolve them as
external symbols. But we are lucky that they have "." in their name,
so the external linker see them as Forwarder RVA exports. See:
- https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#export-address-table
- https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/pe-dll.c;h=e7b82ba6ffadf74dc1b9ee71dc13d48336941e51;hb=HEAD#l972)
This CL changes "." to ":" in symbols name, so theses symbols can not be
found by external linker anymore. So a hacky way is adding the
underscore prefix for these 2 symbols. I don't have enough knowledge to
verify whether adding the underscore for all STEXT/STYPE symbols are
fine, even if it could be, that would be done in future CL.
Fixes #37762
Change-Id: I92eaaf24c0820926a36e0530fdb07b07af1fcc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/317917
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
|
|
Currently, when the runtime printing a stack track (at panic, or
when runtime.Stack is called), it prints the function arguments
as words in memory. With a register-based calling convention,
the layout of argument area of the memory changes, so the
printing also needs to change. In particular, the memory order
and the syntax order of the arguments may differ. To address
that, this CL lets the compiler to emit some metadata about the
memory layout of the arguments, and the runtime will use this
information to print arguments in syntax order.
Previously we print the memory contents of the results along with
the arguments. The results are likely uninitialized when the
traceback is taken, so that information is rarely useful. Also,
with a register-based calling convention the results may not
have corresponding locations in memory. This CL changes it to not
print results.
Previously the runtime simply prints the memory contents as
pointer-sized words. With a register-based calling convention,
as the layout changes, arguments that were packed in one word
may no longer be in one word. Also, as the spill slots are not
always initialized, it is possible that some part of a word
contains useful informationwhile the rest contains garbage.
Instead of letting the runtime recreating the ABI0 layout and
print them as words, we now print each component separately.
Aggregate-typed argument/component is surrounded by "{}".
For example, for a function
F(int, [3]byte, byte) int
when called as F(1, [3]byte{2, 3, 4}, 5), it used to print
F(0x1, 0x5040302, 0xXXXXXXXX) // assuming little endian, 0xXXXXXXXX is uninitilized result
Now prints
F(0x1, {0x2, 0x3, 0x4}, 0x5).
Note: the liveness tracking of the spill splots has not been
implemented in this CL. Currently the runtime just assumes all
the slots are live and print them all.
Increase binary sizes by ~1.5%.
old new
hello (println) 1171328 1187712 (+1.4%)
hello (fmt) 1877024 1901600 (+1.3%)
cmd/compile 22326928 22662800 (+1.5%)
cmd/go 13505024 13726208 (+1.6%)
Updates #40724.
Change-Id: I351e0bf497f99bdbb3f91df2fb17e3c2c5c316dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/304470
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
Change-Id: I6fc8c9ee6d2246bfd874eb58b411e34ddbeaf723
Reviewed-on: https://go-review.googlesource.com/c/go/+/299670
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Currently, in the linker's deadcode pass, when an interface type
is live, the linker thinks all its methods are live, and uses
them to match methods on concrete types. The interface method may
never be used, though.
This CL changes it to only keep used interface methods, for
matching concrete type methods. To do that, when an interface
method is used, the compiler generates a mark relocation. The
linker uses the marker relocations to mark used interface
methods, and only the used ones.
binary size before after
cmd/compile 18887400 18812200
cmd/go 13470652 13470492
Change-Id: I3cfd9df4a53783330ba87735853f2a0ec3c42802
Reviewed-on: https://go-review.googlesource.com/c/go/+/256798
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
The linker prunes methods that are not directly reachable if the
receiver type is never converted to interface. A type can be
converted to interface using reflection through other types.
The linker already takes this into consideration but it missed
the case that the intermediate is a method descriptor. Handle
this case.
Change-Id: I590efc5da163c326db8d43583908a2ef67f65d9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255858
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
interface
Currently, a method of a reachable type is live if it matches a
method of a reachable interface. In fact, we only need to retain
the method if the type is actually converted to an interface. If
the type is never converted to an interface, there is no way to
call the method through an interface method call (but the type
descriptor could still be used, e.g. in calling
runtime.newobject).
A type can be used in an interface in two ways:
- directly converted to interface. (Any interface counts, as it
is possible to convert one interface to another.)
- obtained by reflection from a related type (e.g. obtaining an
interface of T from []T).
For the former, we let the compiler emit a marker on the type
descriptor symbol when it is converted to an interface. In the
linker, we only need to check methods of marked types.
For the latter, when the linker visits a marked type, it needs to
visit all its "child" types as marked (i.e. potentially could be
converted to interface).
This reduces binary size:
cmd/compile 18792016 18706096 (-0.5%)
cmd/go 14120572 13398948 (-5.1%)
Change-Id: I4465c7eeabf575f4dc84017214c610fa05ae31fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/237298
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
|
|
Fixes #38884.
Change-Id: Id5ab9977b6404d0dbf71f13e3e4fefb6868ac802
Reviewed-on: https://go-review.googlesource.com/c/go/+/232377
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
A symbol being reachable doesn't imply its type descriptor is
needed. Don't mark it.
If the type is converted to interface somewhere in the program,
there will be an explicit use of the type descriptor, which
will make it marked.
A println("hello") program before and after
-rwxr-xr-x 1 cherryyz primarygroup 1259824 Apr 30 23:00 hello
-rwxr-xr-x 1 cherryyz primarygroup 1169680 Apr 30 23:10 hello
Updates #38782.
Updates #6853.
Change-Id: I88884c126ce75ba073f1ba059c4b892c87d2ac96
Reviewed-on: https://go-review.googlesource.com/c/go/+/231397
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
reflect.Value.Call, if reachable, used to bring all exported
methods live. CL 228792 fixes this, removing the check of
reflect.Value.Call. This CL adds a test.
Updates #38505.
Change-Id: Ib4cab3c3c86c9c9702d041266e59b159d0ff0a97
Reviewed-on: https://go-review.googlesource.com/c/go/+/228878
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
