https://bugs.webkit.org/show_bug.cgi?id=111764

Reviewed by Oliver Hunt and Geoffrey Garen.
        
The DFG previously ran optimizations to fixpoint because there exists a circular dependency:
        
CSE depends on CFG simplification: CFG simplification merges blocks, and CSE is block-local.
        
CFG simplification depends on CFA and constant folding: constant folding reveals branches on
constants.
        
CFA depends on CSE: CSE reveals must-alias relationships by proving that two operations
always produce identical values.
        
Arguments simplification also depends on CSE, but it ought not depend on anything else.
        
Hence we get a cycle like: CFA -> folding -> CFG -> CSE -> CFA.
        
Note that before we had sparse conditional CFA, we also had CFA depending on CFG. This ought
not be the case anymore: CFG simplification should not by itself lead to better CFA results.
        
My guess is that the weakest link in this cycle is CFG -> CSE. CSE cuts both ways: if you
CSE too much then you increase register pressure. Hence it's not clear that you always want
to CSE after simplifying control flow. This leads to an order of optimization as follows:
        
CSE -> arguments -> CFA -> folding -> CFG
        
This is a 2.5% speed-up on SunSpider, a 4% speed-up on V8Spider, a possible 0.3% slow-down
on V8v7, nothing on Kraken, and 1.2% speed-up in the JSRegress geomean. I'll take a 2.5%
speed-up over a 0.3% V8v7 speed-up.

* dfg/DFGDriver.cpp:
(JSC::DFG::compile):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@145143 268f45cc-cd09-0410-ab3c-d52691b4dbfc