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.
