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

x/tools/internal/refactor/inline: good starter projects #63352

Open
3 of 16 tasks
adonovan opened this issue Oct 3, 2023 · 3 comments
Open
3 of 16 tasks

x/tools/internal/refactor/inline: good starter projects #63352

adonovan opened this issue Oct 3, 2023 · 3 comments
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done. Refactoring Issues related to refactoring tools Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@adonovan
Copy link
Member

adonovan commented Oct 3, 2023

Below is a list of starter projects for anyone who wants to get their hands dirty in the inliner logic. Before starting work on any item, please fork it off into a separate issue, briefly stating the approach you plan to take.

  • support inlining of generic functions or methods
  • improve precision of check of whether arg elimination removes last ref to a caller var...
  • ...and instead of preventing elimination, blank out the var decl.
  • avoid imports.Process by reimplementing just the algorithm we need.
  • choose better local names for renaming imports
  • avoid unnecessarily renaming imports (may need additional inputs?)
  • implement "void tail call" strategy (i.e. f() statement before return stmt). If the return stmt is pure, this is sound even if the callee uses defer.
  • implement parameterless call to { stmt; return expr } from one of these contexts:
        //    x, y     = f()
        //    x, y    := f()
        //    var x, y = f()
  • use binding decls even with the literalization strategy: it's easier and more natural to read func() { var param=arg; ... } () than func(param) { ... } (arg). (Beware: binding decls cover params and named result vars; they may need to be teased apart.)
  • clean-up (?): unify pure, duplicable, and effects into a single pass.
  • allow conversions (other than []byte(string), which observably allocates) to be considered duplicable.
  • use callee's FileSet (calleeFset) to format the new node (res.new), as it is mostly callee code. This should reduce comment loss. (Beware: it seems to introduce spurious newlines. Why?)
  • simplify "binding decl" to use param := arg when it's not necessary to state the type.

More challenging projects:

  • Translate if f(); cond { ... } to { fbody; if cond { ... } } when the inlining of f() is not a simple expression.- [ ] Add a control flow analysis that is more precise than the current "single assignment" predicate. Currently, a binding declaration is required if an argument is a variable that is not "single assignment". But if all the assignments can be proved to occur before or after the call (but not during it using lambdas) then a binding declaration may not be needed.
  • Add an alias analysis so that effects on memory by the callee can be localized to particular variables, allowing writes to commute with reads if they cannot alias.
  • Better handling of spread calls (f(g()) where g returns >1 result).
@adonovan adonovan added the Refactoring Issues related to refactoring tools label Oct 3, 2023
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Oct 3, 2023
@gopherbot gopherbot added this to the Unreleased milestone Oct 3, 2023
@prattmic prattmic added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 3, 2023
@aimuz
Copy link
Contributor

aimuz commented Nov 7, 2023

Hello, what do I need to start with

@adonovan
Copy link
Member Author

adonovan commented Nov 7, 2023

Hello, what do I need to start with

Hi @aimuz, thanks for your interest! The task requires at least a little familiarity with the basic concepts of compilers, and with the APIs of Go's go/ast and go/types packages. Otherwise the learning curve will be steeper; you may find https://golang.org/s/types-tutorial helpful.

Does any of the items listed above seem appealing? If there's one in particular that you want to start with, I suggest you create a separate issue for it, claim it for yourself, state briefly (a sentence or two is fine) what approach you plan to take, and ask any question you have about the approach. We can comment on the separate issue without confusing this one.

@aimuz
Copy link
Contributor

aimuz commented Nov 9, 2023

Thanks for the guide, have a nice day!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted NeedsFix The path to resolution is known, but the work has not been done. Refactoring Issues related to refactoring tools Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants