[Bug testsuite/72850] [7 Regression] FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72850

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
Note that c#3-c#5 are referring to a different issue and that issue is being
tracked by bz77445 (profile estimates are mucked up by early jump threading and
as a result we fail to thread a multi-way branch during a later pass, which is
a huge issue).

--


This BZ is just a missed loop peeling opportunity and it's really not a major
missed optimization.

Prior to Jan's change we computed 7 statements in 6 copied blocks -- which is
an indicator that there's likely not much a traditional loop optimizer could do
here, so potentially creating an irreducible loop is unlikely to hurt later
loop optimizations.

Jan's change uses a more standard way to compute costs that is almost certainly
more accurate in the general case.  The net result is we guess that the
resulting region will have 13 insns in 6 copied blocks and thus the perceived
cost is much higher.

However, there's something subtle going on here.  The old heuristic was mostly
concerned with how many gimple statements were in the region (and didn't look
at their complexity).  The new heuristic tries to estimate the number of insns
the gimple statements will generate.  So it's no great surprise that with the
change in base (gimple statement vs RTL insn) that the heuristic gives
different results sometimes.

I'm leaning towards changing the default statement scale factor to account for
the change in the base.  That is sufficient to fix this problem, but likely
won't help 77445.