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)
