Re: [webkit-dev] DFG, inline functions compileing
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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
And I think You talk about JSC compiling, not about DFG JIT work. -- You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 4GB of Storage! http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=116748&STATUS=MAIN ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
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 Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 4GB of Storage! http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=116748&STATUS=MAIN ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
I'm not talking about the C++ compiler compiling the DFG. I'm instead referring to the DFG compiling JS code. -Filip On Jun 17, 2012, at 1:06 AM, Zoltan Herczeg wrote: > Where are they compiled twice? If in the object file, than it is ok, since > the compiler must provide a standalone function for even inline ones. It > is needed if the function is passed as pointer. These extra functions > should be thrown out by the linker in the final binary. > > Regards, > Zoltan > >> It's a bug. It's not a show stopper but if you've got a fix, I'd encourage >> you to submit a patch. >> >> -Filip >> >> On Jun 16, 2012, at 1:01 PM, Nare Karapetyan wrote: >> >>> Why in DFG inline functions are optimized(compiled) more than >>> once - one time itself and then in caller function's body? >>> >>> -- >>> >>> >>> ___ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
Where are they compiled twice? If in the object file, than it is ok, since the compiler must provide a standalone function for even inline ones. It is needed if the function is passed as pointer. These extra functions should be thrown out by the linker in the final binary. Regards, Zoltan > It's a bug. It's not a show stopper but if you've got a fix, I'd encourage > you to submit a patch. > > -Filip > > On Jun 16, 2012, at 1:01 PM, Nare Karapetyan wrote: > >> Why in DFG inline functions are optimized(compiled) more than >> once - one time itself and then in caller function's body? >> >> -- >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DFG, inline functions compileing
It's a bug. It's not a show stopper but if you've got a fix, I'd encourage you to submit a patch. -Filip On Jun 16, 2012, at 1:01 PM, Nare Karapetyan wrote: > Why in DFG inline functions are optimized(compiled) more than > once - one time itself and then in caller function's body? > > -- > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DFG, inline functions compileing
Why in DFG inline functions are optimized(compiled) more than once - one time itself and then in caller function's body? -- You Rock! Your E-Mail Should Too! Signup Now at Rock.com and get 4GB of Storage! http://connections.rock.com/user/displayUserRegisterPage.kickAction?as=116748&STATUS=MAIN ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev