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
> [email protected]
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
