https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68947
Bug ID: 68947
Summary: CFG expansion computes incorrect frequencies with
-ftree-parallelize-loops=4
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kelvin at gcc dot gnu.org
Target Milestone: ---
Consider the existing test program: testsuite/gcc.d/torture/pr52429.c
Compile with options -S -O3 -ftree-parallelize-loops=4 -S -m64 -da -o pr52429.s
Examine the control-flow-graph represented at the end of the generated dump
file pr52429.c.205r.expand, starting with the label:
;; Full RTL generated for this function
The control-flow graph consists of the following blocks
bb2: 0 -> bb4 (75%), bb9(25%)
bb4: 80 -> bb5 (0%), bb6(100%)
bb9: 80 -> bb4(100%)
bb5: 80 -> bb10(100%)
bb6: 80 -> bb7(100%)
bb7: 7920 -> bb7(100%), bb8(0%)
bb8: 0 -> bb10(100%)
bb10: 0
In order of "decreasing significance", the problems with the frequency values
associated with each basic block are that:
1. The loop comprised of bb7 has an incoming frequency of 80, but an outgoing
frequency of 0. For every loop, the sum of incoming edge frequencies should
equal the sum of outgoing edge frequencies.
2. bb9, which is reached with 25% probability from bb2, has frequency 80. But
bb2 has frequency 0. 25% of 0 is 0.
3. bb5, which is reached with 0% probability from bb4, has frequency 80. It
should have frequency 0, since 0% of 80 is 0.
4. bb10, which is reached with 100% probability from bb8 and with 100%
probability from bb5, should have frequency 80 instead of 0. That's because
100% of 80 is 80.
