https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90168
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |WAITING Last reconfirmed| |2019-04-19 CC| |ebotcazou at gcc dot gnu.org Summary|Unstable register |context-sensitive local |allocation result for same |register allocation |source code | Ever confirmed|0 |1 Severity|normal |minor --- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > Supposed a function as the following, in which 'cond', 'S1' and 'S2' are > completely irrelevant, means they do not access same variables(in term of > RA, they own separate live range set). > > f1() > { > if (cond) { > S1 > } else { > S2 > } > } > > Ideally, we can expect that register allocation on 'S1'is totally > independent of 'S2', w or w/o which makes no difference. This seems a rather far-fetched assumption, to say the least. This would essentially imply that no global optimization is applied to the function. > Its result should be same as below function consisting of only 'S1': > > f2() > { > S1 > } > > But we found gcc does not has this property. Strictly speaking, this is not > a bug, but exposes some kind of instability in code generation, has > undeterminable impact on some optimization, such as inlining. And do you know of any non-toy/production compiler that has the property? > Investigation shows this is related to integer-based frequency normalization > (REG_FREQ_FROM_BB) used by RA, which always rounds up a small frequency > (less than 1) to 1. In foo1(), introduction of new code makes profile counts > of CODES be decreased, so that impact of frequency normalization error > becomes more significant and actually distorts original proportion of > profile counts among basic blocks in CODES. For example, in foo(), two > blocks have counts of 3 and 100 receptively, and in foo1(), they become 0.3 > and 10, after rounding up, they are 1 and 10, thus proportion is changed > from (3 vs 100) to (1 vs 10). > > Possible solution might be to adjust two scale factors used by > REG_FREQ_FROM_BB : REG_FREQ_MAX and BB_FREQ_MAX, or to use float type to > hold frequency? Which version of the compiler are you using? This changed in GCC 8.