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.

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: record and use per-function optimization data #25999

Open
josharian opened this issue Jun 21, 2018 · 5 comments
Open

cmd/compile: record and use per-function optimization data #25999

josharian opened this issue Jun 21, 2018 · 5 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

Comments

@josharian
Copy link
Contributor

This is an open-ended performance idea to explore.

We have per-function compiler-specific export data (see method funcExt in iexport.go). We could do some analysis in package ssa of return values, add that to the export data, and use it on import. This might help with function calls that cannot be inlined.

For example, we could record whether a return value is known to be non-nil. Or a known limited range for a return value. Or a concrete type for a function that returns an interface.

Related: #25862. If we pursue this idea, the mechanism for using info about the return values could be re-used with some annotation for #25862. And possibly also to generalize and simplify the ssa rule "don't nilcheck the return value of newobject".

We could also return things like the ratio of Nodes to instructions, which we might want to use to improve downstream inlining decisions.

One weird thing about doing this is that calling functions from imported packages might optimize further than calling functions from within the same packages. (A similar problem arises for some of the ideas mooted in #17566.) Still probably worth exploring.

cc @randall77 @martisch @dr2chase @cherrymui

@josharian josharian added this to the Unplanned milestone Jun 21, 2018
@TocarIP
Copy link
Contributor

TocarIP commented Jun 21, 2018

Sounds interesting! We could also record used registers and avoid spills of unclobbered registers.

@josharian
Copy link
Contributor Author

@TocarIP oooooooooooooooh.

@dr2chase
Copy link
Contributor

This has minor implications for the GC, though it could be arranged that pointers are always spilled, integers perhaps not.

@CAFxX
Copy link
Contributor

CAFxX commented Jun 27, 2018

Would it be possible to also propagate stack usage (if known/constant), so that the caller can call morestack once (to ensure there's enough for both itself and the callees) and the callees can omit the morestack check/call?

@dr2chase
Copy link
Contributor

@CAFxX That becomes possible when goroutine preemption can be done with signals. This is in the pipeline, and with luck will emerge in 1.12. This has some interaction with how the runtime/GC handles stack resizing -- if F calls G calls H, F is responsible for all their frames, if the GC ran during G and reduced the stack to what was adequate for G, a subsequent call to H might overrun the stack. So we'd need to work on some sort of a handshake or marker to prevent this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
None yet
Development

No branches or pull requests

6 participants