-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: binary size explodes for huge return value #38554
Comments
There are some really big static temps used to initialize instances of type We shouldn't be copying from zeroed data to initialize anything - we should just zero it directly. An easier fix would be to allocated all-zero static temps in BSS, so at least they don't bloat the binary. |
It seems that disabling this section of code can avoid the problem. |
I have a fix in the works. |
Change https://golang.org/cl/229704 mentions this issue: |
Change https://golang.org/cl/229707 mentions this issue: |
This triggers in 131 functions in std+cmd. In those functions, it often helps considerably (2-10% text size reduction). Noticed while working on #38554. Change-Id: Id0dbb8e7cb21d469ec08ec3d5be9beb9e8291e9c Reviewed-on: https://go-review.googlesource.com/c/go/+/229707 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
We set up static symbols during walk that we later make copies of to initialize local variables. It is difficult to ascertain at that time exactly when copying a symbol is profitable vs locally initializing an autotmp. During SSA, we are much better placed to optimize. This change recognizes when we are copying from a global readonly all-zero symbol and replaces it with direct zeroing. This often allows the all-zero symbol to be deadcode eliminated at link time. This is not ideal--it makes for large object files, and longer link times--but it is the cleanest fix I could find. This makes the final binary for the program in golang#38554 shrink from >500mb to ~2.2mb. It also shrinks the standard binaries: file before after Δ % addr2line 4412496 4404304 -8192 -0.186% buildid 2893816 2889720 -4096 -0.142% cgo 4841048 4832856 -8192 -0.169% compile 19926480 1992243 -4048 -0.020% cover 5281816 5277720 -4096 -0.078% link 6734648 6730552 -4096 -0.061% nm 4366240 4358048 -8192 -0.188% objdump 4755968 4747776 -8192 -0.172% pprof 14653060 14612100 -40960 -0.280% trace 11805940 1177726 -28672 -0.243% vet 7185560 7181416 -4144 -0.058% total 113588440 113465560 -122880 -0.108% And not just by removing unnecessary symbols; the program text shrinks a bit as well. Fixes golang#38554 Change-Id: I8381ae6084ae145a5e0cd9410c451e52c0dc51c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/229704 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
This triggers in 131 functions in std+cmd. In those functions, it often helps considerably (2-10% text size reduction). Noticed while working on golang#38554. Change-Id: Id0dbb8e7cb21d469ec08ec3d5be9beb9e8291e9c Reviewed-on: https://go-review.googlesource.com/c/go/+/229707 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
https://play.golang.org/p/OZpuS_MxVNx
What did you expect to see?
A binary file less than 2MB.
What did you see instead?
A binary file of ~514MiB size.
For what it's worth, gccgo produces a sane binary (38KiB, dynamic linking).
The text was updated successfully, but these errors were encountered: