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: detect call trees that can be marked NOSPLIT #17023

Open
josharian opened this Issue Sep 7, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@josharian
Contributor

josharian commented Sep 7, 2016

CL 24814 contains a minor optimization for 386/amd64: Ignore a few common runtime functions that take no arguments when deciding whether a function is a leaf function and is thus eligible for being marked NOSPLIT and thus having no function prolog.

Keith suggested some ways during code review to make this analysis much more powerful. This issue is a reminder to investigate those suggestions.

@josharian josharian added this to the Unplanned milestone Sep 7, 2016

@martisch

This comment has been minimized.

Member

martisch commented Sep 8, 2016

link to code review: https://golang.org/cl/24814/

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Sep 8, 2016

Indeed I've been thinking about something similar at link time, where we know the full call tree (at least for internal static linking), initially motivated for reducing binary size. But I am not sure about the complexity vs. gain (indirect calls are tricky). I may do some experiment.

@josharian

This comment has been minimized.

Contributor

josharian commented Sep 8, 2016

I'd be surprised if this had a significant impact on binary size. The prologues aren't that big.

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Sep 8, 2016

I agree that the benefit may be quite small. So it might not be worth doing...

@josharian

This comment has been minimized.

Contributor

josharian commented Sep 9, 2016

There could still be nice perf improvements. The CL above picks up a percent or two in the encoding/binary benchmarks.

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