Skip to content
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.

Sign up for GitHub

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

Jump to bottom

cmd/compile: reduce generated algs for compiler created array types #28639

Open
martisch opened this issue Nov 7, 2018 · 3 comments
Open

cmd/compile: reduce generated algs for compiler created array types #28639

martisch opened this issue Nov 7, 2018 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone
Backlog

Comments

@martisch
Copy link
Contributor

martisch commented Nov 7, 2018 •
edited

There are alot of types algs that seem to be generated due to slicelit initializations:

example from go binary:

TEXT type..hash.[11]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[12]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[186]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[20]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[28]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[2]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[3]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[41]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[5]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[6]debug/elf.intName(SB) <autogenerated>
TEXT type..hash.[9]debug/elf.intName(SB) <autogenerated>

There are a few other places were the compiler constructs an array type (e.g. non escaping small slice) where algs are likely not needed.

We should vet the compiler for compiler created types (sinit.go, walk.go) that dont need algs and do a SetNoalg where algs are not needed.

Some overzealous application of SetNoalg on new array types in gc seems to remove the above examples and saves ~45kbyte from the go binary. This might be an upper bound because maybe for some cases we will need them.

I have some other ideas/cls to improve algs (or remove them) for go1.13 so happy to work on this.

@josharian @randall77
@martisch martisch self-assigned this Nov 7, 2018
@martisch martisch added this to the Go1.13 milestone Nov 7, 2018
@martisch martisch added Performance NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 7, 2018
@josharian
Copy link
Contributor

Great. IIRC, the alg generation code could be significantly cleaned up. See also #17029 and #17031 and #9930.

@martisch
Copy link
Contributor Author

martisch commented Nov 7, 2018

@josharian thanks I had not had #9930 on my list to look into yet. The alg generation code itself could likely also benefit from a bit of restructuring to e.g. use mkcall1 and other helpers instead of constructing the funcs directly.

@josharian
Copy link
Contributor

Also related: #23929

@martisch martisch mentioned this issue Feb 28, 2019
Open
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@martisch martisch mentioned this issue May 1, 2020
Open
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Backlog
Development

No branches or pull requests
5 participants
@josharian @rsc @martisch @andybons @gopherbot