[webkit-dev] DFG, inline functions compileing

[Filip Pizlo]

On Jun 19, 2012, at 5:04 AM, Nare Karapetyan wrote:

> If the object file is meant by a cfg IR dump, then yes.
> Assume that all of repeated compilations are okay,
> but then again going through all the passes of the optimizations
> in caller function probably does not make sense.
> Or I'm not right?

You've got the right intuition, but there are some subtleties:

- If a function gets hot enough to warrant DFG optimizations then some callsites that may dispatch to that function may decide to inline it, while others won't.  Currently our heuristics are such that when a function gets inlined, it will also usually but not always get compiled stand-alone for the benefit of callsites that choose not to inline.  I don't believe those heuristics are right, and we can easily improve them by triggering baseline->DFG tier-up in prologues rather than in epilogues.  We could even go further and say that when tier-up is triggered we walk the stack to find the first known-hot method and only optimize that one.  But even if you did that, you may have situations where a function foo() calls function bar() in two places, and we choose to inline bar() into foo() at the first callsite but not the second one.  This can happen if the second callsite has gone polymorphic.  My gut feeling is that any optimizations you did to avoid compiling bar() would have only fairly limited benefit because polymorphic callsites are rather common in JS.

- The two compilations that you speak of can be arbitrarily far apart in time.  Hence, if we wanted to cache compilation artifacts from one to the other, we'd risk increasing memory footprint.  The DFG IR requires a fair amount of memory, so it's not clear that doing such caching would be better than reparsing from bytecode.

- Even if you believed that the DFG IR was compact enough to cache - or if you came up with fancy ways to compress it - you'd still have a much bigger problem: every time that we parse bytecode into DFG IR we will likely do subtly different optimizations, because we will likely have subtly different profiling data and watchpoint state.  For example, on the first compilation we may see that some prototype P has some set of fields {F, G, H} that are all specialized to functions.  This allows us to use really aggressive optimizations on method calls that have P in the prototype chain.  But between this compilation and the next one, someone might delete field F, store a string into field G, and install a getter on H that does arbitrary things when called (triggers navigation, starts workers, does XML requests, whatever).  Then the second compilation would actually parse the bytecode differently, and would produce a different DFG IR to reflect the fact that it would be neither wise nor sound to perform the same optimizations that we had performed before.  And by the way, the previous compilation would now be invalidated because of changes in P's state, but that's a different issue.

- Even if you believed that you could make the bytecode->DFGIR parsing deterministic, then you still wouldn't be able to cache anything more than the IR immediately after parsing.  It would not be possible to cache the results of any subsequent phase, since the subsequent phases do whole-compilation-unit analyses of the IR.  For example if you have foo() calls bar(a, b, c) and bar() gets inlined, then the subsequent phases would treat the arguments a, b, c to bar() rather differently than if bar() had not been inlined.  Any type information available at bar()'s callsite would be propagated into bar().  Likewise, any type information available at bar()'s return point would be propagated back into foo().  There is no sane way to make this behave the same if bar() is not inlined as it would behave when bar() is inlined.  I mean, you could turn off all of the optimizations we do that are based on whole-compilation-unit static analysis, but then you'd get a disastrous slow-down on the benchmarks.

-Filip



> 
> --
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120619/d259950f/attachment.html>