https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #31 from Wilco <wdijkstr at arm dot com> --- (In reply to Jan Hubicka from comment #30) > > > > 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. > > This is the issue with jump threading code no longer sanely updating profile, > right? I will try to find time to look into it this week. I don't know the exact details but James proved that the blocks are incorrectly assumed cold so part of the optimization doesn't trigger as expected. I'm not sure whether that is because the frequencies got too low, set incorrectly or not set at all. > > 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. > > There are --param options to control this. They was originally tuned based on > Spec2000 and x86_64 scores (in GCC 3.x timeframe). if you can get resonable > data that they are not working very well anymore (or for ARM), we could try > to > tune them better. > > I have WIP patches to get the propagation bit more fine grained and > propagate i.e. > info if BB is reachable only bo known to be cold path (such that one that has > EH edge on it). This may make the logic bit more reliable. I'll have a look, but I think the key is to think in terms of block importance (from cold to hot). Apart from highly skewed cases (eg. exception edges or loops), most blocks should be equally important to optimize.
