Re: [webkit-dev] DFG, inline functions compileing

2012-06-19 Thread Nare Karapetyan
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=116748STATUS=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

2012-06-19 Thread Nare Karapetyan
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=116748STATUS=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

2012-06-19 Thread 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@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

2012-06-17 Thread Zoltan Herczeg
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 n...@rock.com 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

2012-06-17 Thread Filip Pizlo
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 zherc...@webkit.org 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 n...@rock.com 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

2012-06-16 Thread Filip Pizlo
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 n...@rock.com 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