Re: 100x -O0 Compile Time Regression {3.2,3.3} -> {3.4,3.5}

[Daniel Berlin <dberlin at dberlin dot org>]

> Daniel, could you please also measure compile time on some less
> artificial examples than 20001226-1.c before commiting this patch?  It
> adds one unnecessary recount of whole dominator tree, so it might
> be that it would not be win on usual functions not countaining 
> thousands
> of critical edges.
I thought about this before "submitting" the patch.
as Jeff pointed out, "et_splay with a whopping 27% of all the events 
within cc1 (cc1 has just over 40% of the total events during make-k 
check run)".
Even on "more normal" cases, it can take up a significant amount of 
time, because we perform the recount every time we split an edge (which 
can happen any number of times during splitting critical edges).  
That's obviously quadratic in the number of split edges.
The only cases where the "submitted" version could a lose is where we 
didn't *actually* need to recompute the dominators (because we didn't 
split an edge).  I can take care of this if it's actually a time sink.


> If it showed up to be case, something would have to be done about
> updating dominators in split_edge to avoid the quadratic behavior it
> exhibits on this testcase.