https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #30 from Jan Hubicka <hubicka at ucw dot cz> --- > > 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 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. Honza
