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

upon inlining, propagate more precise type info for callee's arguments #5849

Closed
scabug opened this issue May 28, 2012 · 3 comments
Closed

upon inlining, propagate more precise type info for callee's arguments #5849

scabug opened this issue May 28, 2012 · 3 comments

Comments

@scabug
Copy link

scabug commented May 28, 2012

An observation about inlining in [1]:

inlining is a powerful enabling optimization; by eliminating the actual call it not only offers an obvious direct benefit but also indirect benefits, as information about the method's arguments is propagated from caller to callee. 

Currently Inliner does not propagate the arguments' (more precise) types (in particular an anonymous class) to the callee formals (we leave it for the JVM to figure that out).

In more detail, dupLocal() in doInline() creates local vars for the args of the inlined callsite. Rather than giving them the types obtained via TFA, it reuses those for the callee's formal params. Moreover, during:

/** Map an instruction from the callee to one suitable for the caller. */
def map(i: Instruction): Instruction = {

there's an opportunity to devirtualize calls (in the inlined callee).

Citation:

[1] Andreas Sewe, Jannik Jochem, and Mira Mezini. 2011.
Next in line, please!: exploiting the indirect benefits of inlining by accurately predicting further inlining.
SPLASH '11 Workshops. ACM, New York, NY, USA, 317-328.
http://doi.acm.org/10.1145/2095050.2095102

@scabug
Copy link
Author

scabug commented May 28, 2012

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

@scabug
Copy link
Author

scabug commented May 31, 2012

@magarciaEPFL said:
One more TODO: the TFA should track non-nullness (necessary for #5850) and type-exactness (as resulting from new).

@SethTisue
Copy link
Member

closing old backend tickets (unless someone can show it's still relevant to current Scala)

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

No branches or pull requests

2 participants