warning: At the end of the day, could not inline @inline-marked method minus>
/Users/grek/scala/scala/Arrow.scala:23: warning: At the end of the day, could not inline @inline-marked method any2ArrowAssoc
"foo" -> "bar",
^
/Users/grek/scala/scala/Arrow.scala:24: warning: At the end of the day, could not inline @inline-marked method any2ArrowAssoc
"foo" -> "bar"
^
warning: At the end of the day, could not inline @inline-marked method minus>
warning: At the end of the day, could not inline @inline-marked method minus>
5 warnings found
I debugged the inliner and it turns out that it simply gives up too early. The relevant line is Inliners.scala:561:
while (retry && count < MAX_INLINE_RETRY)
Here the count is greater than MAX_INLINE_RETRY so inliner just gives up. I'm wondering if it would make sense to tweak the condition so inliner always tries to inline everything that is marked with @inline and only if it exhausts all options (so it inlines everything or there's no way to continue inlining) it abort. Basically, the idea is that @inline annotation enforces inlining no matter what heuristics say.
Miguel, would that make sense in your opinion?
--
Grzegorz
Greg,
In that case, upon inlining, you want `count` not to be increased when the callee is marked @inline. The relevant line is:
if (isCountable) { count += 1 };
Currently `isCountable()` doesn't do what you want, but can be easily modified, as follows:
/* count only callees other than:
* (a) methods owned by anon-closure-classes;
* (b) @inline-marked methods;
* (c) `foreach`, `filter`, `withFilter`, `map`, `flatMap`; and
* (d) those in RuntimePackage.
*/
val isCountable = !(
isClosureClass(receiver)
|| hasInline(concreteMethod) // <------- just added
|| hasInline(inc.sym) // <------- just added
|| isMonadicMethod(concreteMethod)
|| receiver.enclosingPackage == definitions.RuntimePackage
)
if (isCountable) { count += 1 };
The updated definition of `isCountable` now appears right before the single use it sees. Readability.
Greg,
In that case, upon inlining, you want `count` not to be increased when the callee is marked @inline. The relevant line is:
if (isCountable) { count += 1 };
Currently `isCountable()` doesn't do what you want, but can be easily modified, as follows:
/* count only callees other than:
* (a) methods owned by anon-closure-classes;
* (b) @inline-marked methods;
* (c) `foreach`, `filter`, `withFilter`, `map`, `flatMap`; and
* (d) those in RuntimePackage.
*/
val isCountable = !(
isClosureClass(receiver)
|| hasInline(concreteMethod) // <------- just added
|| hasInline(inc.sym) // <------- just added
The following commit contains that patch and compiles:
https://github.com/magarciaEPFL/scala/commit/39007f1d51affb9b56b4d4347ada26574b49960b
`inc` is a wrapper (IMethodInfo) that provides some utilities to find things about the callee.
Talking about patches to the inline, here's the PR from yesterday about publicizing outer fields only:
https://github.com/scala/scala/pull/1115
On 11 August 2012 17:56, Miguel Garcia <miguel...@tuhh.de> wrote:The following commit contains that patch and compiles:
https://github.com/magarciaEPFL/scala/commit/39007f1d51affb9b56b4d4347ada26574b49960b
`inc` is a wrapper (IMethodInfo) that provides some utilities to find things about the callee.I see. I didn't know you moved the method. I tried your commit and it helps with getting rid of 586 of inliner warnings. However, the price seems to be rather high: `ant build-opt` takes 19% longer on machine.
We can consider this for Scala 2.11.1.
--
Grzegorz KossakowskiScalac hacker at Typesafetwitter: @gkossakowskigithub: @gkossakowski
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Greg, the whole point of 'isCountable' is precisely to keep inlining under a reasonable budget. Definitely increasing the retry count is the wrong way about it. I bet that the number of @inline methods is much smaller than the total count of methods that could be inlined.
Iulian, I don't understand that part of inliner so it's great you joined the conversation :-)On 13 March 2014 16:22, iulian dragos <jagu...@gmail.com> wrote:
Greg, the whole point of 'isCountable' is precisely to keep inlining under a reasonable budget. Definitely increasing the retry count is the wrong way about it. I bet that the number of @inline methods is much smaller than the total count of methods that could be inlined.Does each iteration inline just one method invocation?
What would be a good way to convince inliner to always inline all method calls marked with @inline?
--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.