[webkit-dev] recompilation in dfg

2012-10-12 Thread Blake Fiddler
Hi.
I have some example in which my function recompiling in dfg jit (it's
parsing in second time without OSR exits).
Can you explain me why that happens and in which cases?

Regards, Blake.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] WebKitQt

2012-08-16 Thread blake fiddler
Hey!

I have problem with WebKit  Qt port build.
Why you disable Qt4.x ??? As I can understand now WebkitQt works only with
5.0 version?
But Qt5 isn't stable version - it's beta.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] DFG optimizations

2012-05-23 Thread blake fiddler
Hi,
Have you some news about dfg optimisations? what are you planing, what have
you now or what is your current work ?

Currently we do not have either LICM, or loop peeling, or GCSE. We do have
 a patch that implements LICM, but we are letting it simmer for now because
 under the current DFG IR, it is somewhat of a complicated beast. My main
 concern is just bug tail, due to the various stunts that the current LICM
 patch has to do to fool the DFG into moving code between basic blocks.

 We're fixing that by steadily moving the DFG IR towards SSA. Once we
 finish that, I think we'll implement either LICM or peeling+GCSE based on
 whatever appears to be the simplest. We already know that LICM is a pure
 performance win; but on the other hand, GCSE is likely to be more generic.
 I tend to think that extending our current CSE framework to support some
 maximally-profitable subset of GCSE will not be terribly difficult.

 We don't currently have PRE. It's not on my short list of optimizations to
 implement.

 But if we wanted to go down that route, it might be interesting to
 consider something like Van Drunen's GVN-PRE [1]. I have already been
 thinking about implementing GVN; maybe just going straight for GVN-PRE
 would turn out to be easy enough. But it goes without saying that GVN alone
 is a dead-simple optimization compared to Van Drunen's work, and, even
 according to his performance results, PRE is a *tiny* win over simpler
 redundancy elimination optimizations.

 -Filip

 [1] ftp://ftp.cs.purdue.edu/pub/hosking/papers/a-ssapre.pdf



 On Mar 25, 2012, at 4:59 PM, Nare Karapetyan wrote:

  HI!
 
  There is a discussion about LICM implementation in DFG in one of
 previous posts.
  There it was said that the developers had not decided yet which
 optimization to do: LICM or loop peeling with global CSE.
  So is there any progress in this direction?
 
 
  And about CSE, does it include the partial redundancy elimination (PRE)?
 
 
  --
 
 
  ___
  webkit-dev mailing list
  webkit-dev@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/20120325/a57e47fa/attachment-0001.html
 

 --

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


 End of webkit-dev Digest, Vol 82, Issue 38
 **

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


[webkit-dev] DFG jit Type checking

2012-03-15 Thread blake fiddler
I'm trying to figure out how does the DFG JIT type checking work?
I'm also interested in the following: if I start DFG JIT without using LICM
will the types of variables be checked in the cycle? To make it clear, I'll
bring this example
for (var j=0; j1; j++)
{
var i = 10;
var h = j + i;
}

How will the type of variable  i  be checked in that example?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev