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 

- 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.


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

webkit-dev mailing list

Reply via email to