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: reduce generated algs for compiler created array types #28639

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

Comments

Projects
None yet
2 participants
@martisch
Member

martisch commented Nov 7, 2018

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

@josharian

This comment has been minimized.

Contributor

josharian commented Nov 7, 2018

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

@martisch

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

josharian commented Nov 8, 2018

Also related: #23929

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment