https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #29 from Wilco <wdijkstr at arm dot com> --- (In reply to Jan Hubicka from comment #28) > > On SPEC2000 the latest changes look good, compared to the old predictor gap > > improved by 10% and INT/FP by 0.8%/0.6%. I'll run SPEC2006 tonight. > > It is rather surprising you are seeing such large changes for one branch > predictor > change. Is most of it really comming just from the bb-reorder changes? On > x86 the > effect is mostly within noise and on Itanium Gap improve by 2-3%. > It may be interesting to experiment with reorderin and prediction more on > this target. When I looked at gap at the time, the main change was the reordering of a few if statements in several hot functions. Incorrect block frequencies also change register allocation in a bad way, but I didn't notice anything obvious in gap. And many optimizations are being disabled on blocks with an incorrect frequency - this happens all over the place and is the issue causing the huge Coremark regression. I could do some experiments but I believe the key underlying problem is that GCC treats the block frequencies as accurate when they are really very vague estimates (often incorrect) and so should only be used to break ties. In fact I would claim that even modelling if-statements as a balanced 50/50 is incorrect. It suggests that a block that is guarded by multiple if-statements handling exceptional cases is much less important than the very same block that isn't, even if they are both always executed. Without profile data providing actual frequencies we should not optimize the outer block for speed and the inner block for size.
