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

Jump to bottom

inlining creates duplicates when anon-closure-class can't be eliminated after all #5950

Closed
scabug opened this issue Jun 19, 2012 · 4 comments
Closed

inlining creates duplicates when anon-closure-class can't be eliminated after all #5950

scabug opened this issue Jun 19, 2012 · 4 comments
Labels
enhancement optimizer

Comments

@scabug
Copy link

scabug commented Jun 19, 2012

Sometimes it happens that"

  • an anon-closure's apply() gets inlined (let's call that method A), but
  • a sibling method invoked by A (ie also owned by A's owner) doesn't get inlined (that sibling method is usually an specialized apply).
    In general, whenever the instance of the anon-closure-class is used somehow.

As a result, the anon-closure-class can't be eliminated, and we end up emitting code duplicates (for the method/s that did get inlined). When compiling the compiling under -optimize about 600 anon-closure-classes are prone to this. In these cases it would be best not to inline at all.

Somewhat related,

  • private members of anon-closure-classes that aren't used in their owning classes could be removed by DeadCodeElimination.
  • more aggressively, any synthetic private member that can't be accessed from a non-private member could be removed (no statistics gathered yet on the eventual bytecode reduction).
  • doing that for non-synthetic private members would go too far.
@scabug
Copy link
Author

scabug commented Jun 19, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5950?orig=1
Reporter: @magarciaEPFL

@scabug
Copy link
Author

scabug commented Jun 19, 2012

@magarciaEPFL said:
The following quick hack (visiting anon-closure-classes in a compilation unit before other classes) won't do the trick:

  class InliningPhase(prev: Phase) extends ICodePhase(prev) {
    def name = phaseName
    val inliner = new Inliner

    override def apply(unit: global.CompilationUnit) {
      val Pair(anonClos, nonAnonClos) = unit.icode partition { ic => isClosureClass(ic.symbol) }
      anonClos    foreach apply
      nonAnonClos foreach apply
    }

@SethTisue
Copy link
Member

@lrytz should this stay open?

@lrytz
Copy link
Member

lrytz commented Mar 7, 2018

let's track it here scala/scala-dev#53

@lrytz lrytz closed this as completed Mar 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement optimizer
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lrytz @SethTisue @scabug