https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90168
--- Comment #2 from Feng Xue <fxue at os dot amperecomputing.com> --- (In reply to Eric Botcazou from comment #1) > > 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? llvm has, and icc nearly has(only minor difference in register number, but completely same spills). > > > 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. GCC trunk (9.0.1 20190325)